-
Notifications
You must be signed in to change notification settings - Fork 14.1k
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
Removed mapped tasks block all_success trigger rule #33164
Comments
@tanelk Could you please provide an example of DAG? |
Can you please provide reproduction steps? Also, what do you mean by the following:
How are the number of mapped task instances decreasing during a DAG run? |
Example DAG
Let it complete and then return one less element from the The In this very simple DAG, the run will be failed with On more complex structures the deadlock detection might not kick in. |
I tried to run this example with the v2.9.3 (first run with original DAG, remove one element, and clear one DAG run) and I didn't manage to reproduce it - all tasks succeeded. |
I don't have time to make a reproducible example, but this happened to me on Airflow 2.6.2. I manually delete the removed task for the time being until I can try this on a newer version |
Apache Airflow version
2.6.3
What happened
When rerunning a DAG run with dynamically mapped tasks and the number of mapped task instances degreases, then downstream tasks with all_success trigger rule (likely some others as well) will not get scheduled, because removed status is not considered to be successful. When a regular task gets removed, then this does not happen, because it will get removed from the DAG structure.
Task dependency message
Task's trigger rule 'all_success' requires all upstream tasks to have succeeded, but found 2 non-success(es). upstream_states=_UpstreamTIStates(success=22, skipped=0, failed=0, upstream_failed=0, removed=2, done=24), upstream_task_ids={'upstream_task'}
Previously you could forcefully run it with the "run" button in UI, but it has been removed in one of the resent releases.
Luckily I could delete the removed TIs and then the downstream tasks got rescheduled, but this is not "scalable".
What you think should happen instead
Removed TIs should not block any trigger rules from getting executed.
How to reproduce
Operating System
Versions of Apache Airflow Providers
No response
Deployment
Virtualenv installation
Deployment details
No response
Anything else
No response
Are you willing to submit PR?
Code of Conduct
The text was updated successfully, but these errors were encountered: