-
Notifications
You must be signed in to change notification settings - Fork 14.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
successful DAG run fails to be scheduled after being manually cleared if Dag.dagrun_timeout is set #14265
Comments
maybe a duplicate of #13853. |
Can you test it with 2.0.1 too please @YangMuye ? |
@kaxil tested with 2.0.1. It has the same issue.
|
It seems that the dag run does not need to be successful first to hit this issue. |
@YangMuye @kaxil Line 1328 in 09327ba
airflow/airflow/models/taskinstance.py Line 221 in 09327ba
Alternatively, the browse DAG runs view uses a different path to clear dag runs, and is still effective in resetting the dagrun start date: Line 3429 in 09327ba
We've advised our users to use this method as a workaround for now, and set our normal 24 hour dag_run timeout to 7 days to cover most common use cases of clearing recently failed runs. |
I suspect this will be resolved by #16401 when merged. Would wait for it to be merged and reproduce this because it touched on dr.start_date |
Actually this was already fixed in main with #15382 (not sure if it’s intended though). As mentioned above, the issue is caused by
Wait, I was wrong, #15382 was backported to 2.1.1! Could someone verify whether the issue is still present in 2.1.1? |
Closing -- fixed by #16401 -- which will be part of Airflow 2.1.3 |
Apache Airflow version: 2.0.0
Kubernetes version (if you are using kubernetes) (use
kubectl version
):Environment:
uname -a
): 3.10.0-1160.11.1.el7.x86_64What happened:
I cleared a success DAG run and it failed to be scheduled again with the following error message:
After removing dagrun_timeout, the same dag run can be rescheduled.
What you expected to happen:
I expect "timeout" is counted from the moment the DAG is reset.
Anything else we need to know:
I can reproduce it with the following code. Not sure if it is the intended behavior.
The text was updated successfully, but these errors were encountered: