Allow keeping finished task states on Dag run patch#68666
Conversation
There was a problem hiding this comment.
This was deliberately allowed in #66198, both behaviors conflict, we need to decide what we want to do here. An early like this removes a 'feature'.
This was the behavior implemented in 2.x I believe
38d81be to
a52660b
Compare
|
Thanks for the information. In order to resolve the conflict, I made overwriting opt-out instead of removing it: overwrite now defaults to True, keeping the #66198 behavior of re-marking already-finished (success/failed/skipped) tasks. In the UI I added a GitHub-style split button (like the merge dropdown). the main action stays "Confirm with overwrite", and the dropdown switches to "Confirm without overwrite" for overwrite=False. So both behaviors are supported and the default is unchanged. Does that direction work for you? Please feel free to let me know your opinion and happy to refine it to make it better, thanks! Screen.Recording.2026-06-26.at.7.51.41.PM.mov |
a5b3c67 to
723f40d
Compare
There was a problem hiding this comment.
Intead of doing this, I believe similarly to the set_dag_run_state_to_failed, the set_dag_run_state_to_success should:
- Operate only on running states
TaskInstance.state.in_(running_states), - Mark non-finished tasks as SKIPPED
- Do not skip teardown tasks
That would solve it. Basically having a set_dag_run_state_to_success closer to set_dag_run_state_to_failed.
(Which is a simpler PR overall)
723f40d to
6522569
Compare
|
Updated as suggested. Success branch now mirrors failed (running → success, non-finished → skipped, teardowns untouched), sharing one implementation. Old approach reverted. |
8ef31db to
fbec914
Compare
fbec914 to
98abe20
Compare
Backport successfully created: v3-3-testNote: As of Merging PRs targeted for Airflow 3.X In matter of doubt please ask in #release-management Slack channel.
|
Related Issue
Related #67695
Why
Re-marking a run to its existing state (success → success) rewrote already-finished task states.
How
Was generative AI tooling used to co-author this PR?
Claude Code with Opus4.8
{pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.