Airflow DAG graph is not drawing the run_id passed as argument

[fbmatilla]

Apache Airflow version

2.5.3

What happened

Through the Web Interface: If we look for a specific DAG run id (before the last 25 runs) and we try to access the graph:

A the details of a different RUNID are really appearing:

Looks like the issue is related to the fact that the RUNID passed as argument is not in the combobox of the default selected runs:

What you think should happen instead

The execution details of the run id passed as argument should be shown.

How to reproduce

Just follow the steps described in the "What happened" section.

Operating System

Ubuntu 20.04.5

Versions of Apache Airflow Providers

apache-airflow-providers-amazon==7.3.0
apache-airflow-providers-celery==3.1.0
apache-airflow-providers-cncf-kubernetes==5.2.2
apache-airflow-providers-common-sql==1.3.4
apache-airflow-providers-databricks==4.0.0
apache-airflow-providers-docker==3.5.1
apache-airflow-providers-elasticsearch==4.4.0
apache-airflow-providers-ftp==3.3.1
apache-airflow-providers-google==8.11.0
apache-airflow-providers-grpc==3.1.0
apache-airflow-providers-hashicorp==3.3.0
apache-airflow-providers-http==4.2.0
apache-airflow-providers-imap==3.1.1
apache-airflow-providers-microsoft-azure==5.2.1
apache-airflow-providers-microsoft-mssql==3.3.2
apache-airflow-providers-mysql==4.0.2
apache-airflow-providers-odbc==3.2.1
apache-airflow-providers-postgres==5.4.0
apache-airflow-providers-redis==3.1.0
apache-airflow-providers-sendgrid==3.1.0
apache-airflow-providers-sftp==4.2.4
apache-airflow-providers-slack==7.2.0
apache-airflow-providers-snowflake==4.0.4
apache-airflow-providers-sqlite==3.3.1
apache-airflow-providers-ssh==3.5.0

Deployment

Official Apache Airflow Helm Chart

Deployment details

No response

Anything else

No response

Are you willing to submit PR?

• Yes I am willing to submit a PR!

Code of Conduct

• I agree to follow this project's Code of Conduct

[boring-cyborg]

Thanks for opening your first issue here! Be sure to follow the issue template! If you are willing to raise PR to address this issue please do so, no need to wait for approval.

[hussein-awala]

I can't reproduce on 2.5.3 🤔 can you share the webserver log when you refresh the page?

[fbmatilla]

Hi Hussein,

Sure. To be able to reproduce it, it is important to access a RunId that is not included in combobox of the latest 25:

In this new example, we are trying to access the run id ES_2023-04-10T09:00:03.594297, however this one CL_2023-04-14T13:00:11.808718 is really appearing.

This are the webserver logs at that time:
ewok-webserver-775db7bf4d-p8m5z.log

[robi-ng]

I'm facing the same issue with Airflow 2.5.3.

[github-actions]

This issue has been automatically marked as stale because it has been open for 30 days with no response from the author. It will be closed in next 7 days if no further activity occurs from the issue author.

[fbmatilla]

Hi, this is still happening in 2.5.3, we should keep it open. Thx.

[sbrinkhorst]

We're facing the same issue. I upgraded from 2.5.1 to 2.5.3 earlier this week. I think the problem was introduced in 2.5.2, at least I still saw it when I downgraded our acceptance environment to that version.

After clicking around a bit we found the following:

In the List Dag Run table there are two columns you can click on: Dag Id and Run Id

If you click on the dag name in the Dag Id column it actually adds the execution date to the url and that typically takes you to the DAG you're looking for:

https://example.com/dags/your-dag/graph?execution_date=2023-05-26+10%3A01%3A31.066801%2B00%3A00

In the Run Id column it also adds the DAG ID to the URL as well:

https://example.com/dags/your-dag/graph?run_id=manual_2023-05-26T10%3A01%3A30.964UTC&execution_date=2023-05-26+10%3A01%3A31.066801%2B00%3A00

It seems that the date selector for the execution date is not filled correctly if you also provide the run_id, and then it defaults to now. Then it tries to look up your run_id, which only succeeds if your run is in the table (so that will be if it in the 25 most recent runs). You can see in the screenshot @fbmatilla provided that the execution_date from the URL does not match the UI.

So I would describe the issue as "DAG graph view does not use execution_date from URL correctly if dag_run is also provided".

The List Task Instance table has the same issue when clicking on the Run Id, that issue was already present for a longer time. (There the Dag Id column doesn't have the execution_date in the URL but you can go via the Task Id column.) Has something been done to make these lists more consistent, but now it is consistently wrong?

[hussein-awala]

I just tested it with 2.6.1 and it seems to work normally.

I created this dag:

import pendulum

from airflow import DAG
from airflow.operators.empty import EmptyOperator

with DAG(
    "debug_dag_run",
    start_date=pendulum.datetime(2023, 5, 1),
    schedule_interval="@daily",
    catchup=True,
):
    EmptyOperator(task_id="empty_task")

which created 25 runs, and I triggered 3 runs manually (28 in total).

When I choose a run before the last 25 runs, the select list is updated to have just this run_id, and the selected graph is updated to the desired run:

I will close the issue as completed.
I let you test with 2.6.1, and we can reopen it if you still have the same issue.

[sbrinkhorst]

Thank you. If I test it locally with that version it works for me again too. We will do the actual upgrade in the next few weeks, but I see no reason why it should not work there.

[shnuwl007]

There is a bug of version 2.5.x, please increase the value of ”default_dag_run_display_number“ in the airflow.cfg file. Its default value is 25, which means it will only return the most recent 25 run_ids belonging to the same dag. If the run_id you are looking for happened earlier, you will not be able to find it.
Or you can added "&num_runs=1000" to the url of the browser, like:
http://localhost:8080/dags/dag_id/graph?run_id=013cdb84-a81f-4369-9e4c-2c7b2d2cb2fb&execution_date=2023-04-20+14%3A48%3A44.795356%2B00%3A00&num_runs=1000

[sbrinkhorst]

Our most used DAG ran close to 90,000 times in the last 30 days, so it is not really feasible for us to rely on increasing the nr of dag runs. We will just upgrade to the new version.

[hterik]

Similar problem present in 2.7.1 #34723

[fbmatilla]

Hi,

confirmed, this is happening again in version 2.7.2, can we open this bug again, please?

Thanks.

[potiuk]

Hi,

confirmed, this is happening again in version 2.7.2, can we open this bug again, please?

Thanks.

Why do you want to reopen it @fbmatilla since this is apparently duplicate of #34723 as @hterik noticed ? Or is it different? Can you take a close look and explain?

[fbmatilla]

Absolutely right. Sorry, I did not see that. Thanks @potiuk.