Repository navigation
Fix deferral paths in task lifecycle diagram - #75428
Merged
Merged
Conversation
The diagram routed tasks with start_from_trigger=True through scheduled, the executor and queued before handing them to the triggerer. The scheduler defers these tasks itself: DagRun.schedule_tis calls TaskInstance.defer_task, which creates the trigger and sets the task instance to deferred, so it never reaches scheduled or queued. It also sent a task whose trigger had fired back through the scheduler's checks, so a start_from_trigger task that finishes on a worker was drawn looping back to the triggerer. When a trigger fires, handle_event_submit sets the task instance to scheduled directly.
shivaam
marked this pull request as ready for review
October 22, 2026 20:51
kaxil
approved these changes
Oct 22, 2026
Both diamonds were labelled "A triggerer task?" but ask different things: the first is start_from_trigger, the second is whether the trigger ends the task (end_from_trigger). With the same label, a start_from_trigger sensor reads as never going back to a worker for next_method. A Human-in-the-loop task leaving awaiting_input also resumes through handle_event_submit, from both the response route and the scheduler's timeout sweep, so it lands in scheduled directly instead of going back through the scheduler's checks.
shivaam
added a commit
to shivaam/airflow
that referenced
this pull request
Oct 23, 2026
Contributor
Backport successfully created: v3-4-testNote: As of Merging PRs targeted for Airflow 3.X In matter of doubt please ask in #release-management Slack channel.
|
kaxil
pushed a commit
that referenced
this pull request
Oct 23, 2026
1 task done
2 tasks done
2 tasks done
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The task lifecycle diagram on the Tasks docs page has a few mistakes on the deferral and resume paths:
start_from_trigger=Trueare drawn going throughscheduled, the executor andqueuedbefore they reach the triggerer. The scheduler defers these tasks itself:DagRun.schedule_tiscallsTaskInstance.defer_task, which creates the trigger and moves the task instance straight todeferred, so it never reachesscheduledorqueued. The check now comes just beforescheduled, andqueuedleads straight to the worker.start_from_triggertask was drawn looping back to the triggerer.handle_event_submitsets the task instance toscheduleddirectly, so that arrow now points atscheduled.awaiting_inputresumes the same way, from both the response route and the scheduler's timeout sweep, so its arrow now points atscheduledtoo.Only the diagram changes. The image and its checksum were regenerated with the
generate-airflow-diagramshook.Before and after
The changed arrows and labels are drawn in red for review only. The committed diagram keeps its usual colours. Click an image to open it at full size.
Before (
main):After (this PR):
The swapped YES/NO labels on "Required upstream task(s) failed?" are fixed separately in #74520. The two changes touch different lines of the script, so whichever merges second only needs the image regenerated.
Was generative AI tooling used to co-author this PR?
Generated-by: Claude Code (Opus 5.5) following the guidelines