You are viewing a plain text version of this content. The canonical link for it is here.

Posted to commits@airflow.apache.org by GitBox <gi...@apache.org> on 2020/10/28 01:41:32 UTC

[GitHub] [airflow] wolfier opened a new issue #11901: DAGs remain in the UI after renaming the dag_id in the same python file

wolfier opened a new issue #11901:
URL: https://github.com/apache/airflow/issues/11901

<!--

Welcome to Apache Airflow! For a smooth issue process, try to answer the following questions.
Don't worry if they're not all applicable; just try to include what you can :-)

If you need to include code snippets or logs, please put them in fenced code
blocks. If they're super-long, please use the details tag like
<details><summary>super-long log</summary> lots of stuff </details>

Please delete these comment blocks before submitting the issue.

-->

<!--

IMPORTANT!!!

PLEASE CHECK "SIMILAR TO X EXISTING ISSUES" OPTION IF VISIBLE
NEXT TO "SUBMIT NEW ISSUE" BUTTON!!!

PLEASE CHECK IF THIS ISSUE HAS BEEN REPORTED PREVIOUSLY USING SEARCH!!!

Please complete the next sections or the issue will be closed.
These questions are the first thing we need to know to understand the context.

-->

**Apache Airflow version**: 1.10.12

**What happened**:

When I rename the dag_id, the new dag_id shows up in the UI but the old dag_id does not disappear and remains in the UI.

**What you expected to happen**:

When Airflow [lists out the python files](https://github.com/apache/airflow/blob/1.10.12/airflow/utils/file.py#L105-L161) and tries to [deactivate the deleted dags during dag processing](https://github.com/apache/airflow/blob/1.10.12/airflow/utils/dag_processing.py#L951-L955), the old DAG's file location is still in the list of the alive DAG location because the new DAG is now defined in the old DAG's python file. Even when you manually set is_active to False in the metastore, the dag processing process will set it back to True.

This happens whether or not DAG serialization is enabled.

**How to reproduce it**:
<!---

As minimally and precisely as possible. Keep in mind we do not have access to your cluster or dags.

If you are using kubernetes, please attempt to recreate the issue using minikube or kind.

## Install minikube/kind

- Minikube https://minikube.sigs.k8s.io/docs/start/
- Kind https://kind.sigs.k8s.io/docs/user/quick-start/

If this is a UI bug, please provide a screenshot of the bug or a link to a youtube video of the bug in action

You can include images using the .md style of
![alt text](http://url/to/img.png)

To record a screencast, mac users can use QuickTime and then create an unlisted youtube video with the resulting .mov file.

--->

I was able to reproduce it by following these steps:
1. Add a python file in the dags folder and initialize the DAG
2. Verify the dag shows up in the UI
3. Change the dag_id in the same file to something else
4. Verify the new dag shows up in the UI
5. Both the old DAG and the new DAG are visible on the UI as well as the metadata db.

```
➜ dags pwd
/Users/alan/projects/astro/dags
➜ dags ls
wow.py
```
```python
from datetime import datetime

from airflow.models import DAG

dag = DAG(
dag_id='yay',
schedule_interval='@once',
start_date=datetime(2020, 1, 1),
catchup=False
)
```

In the screenshot, both DAGs are marked as active but there only one DAG defined in `wow.py`.
<img width="1502" alt="Screen Shot 2020-10-27 at 6 31 40 PM" src="https://user-images.githubusercontent.com/5952735/97380092-8cfb6480-1883-11eb-8315-1b386ffb00d8.png">

**Anything else we need to know**:

<!--

How often does this problem occur? Once? Every time etc?

Any relevant logs to include? Put them here in side a detail tag:
<details><summary>x.log</summary> lots of stuff </details>

-->

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org