Skip to content

Set end date and duration on tasks skipped by a Dag run timeout - #74128

Merged
shahar1 merged 2 commits into
apache:mainfrom
luc-pimentel:fix/58536-dagrun-timeout-skip-end-date
Oct 3, 2026
Merged

shahar1 merged 2 commits into
apache:mainfrom
luc-pimentel:fix/58536-dagrun-timeout-skip-end-date

Conversation

@luc-pimentel

Copy link
Copy Markdown
Contributor

When a Dag run hits dagrun_timeout, the scheduler skips the task that is still running but leaves its end_date and duration empty, so the elapsed time shown for it keeps growing after the task is gone.

The timeout branch of SchedulerJobRunner._schedule_dag_run set the state directly. It now calls TaskInstance.set_state, like the other skip paths, which sets end_date and duration. A task that never started gets the same start and end date and a zero duration, as when a trigger rule skips it.

Tested on 3.3.2 and main with airflow standalone, using a Dag with a 30 s dagrun_timeout and a task that sleeps 120 s, read 150 s after that task started:

Task Before With this change
running when the run timed out skipped, no end date or duration, elapsed time keeps growing skipped, ends at the timeout, 29 s
downstream, never started skipped, no dates skipped, same start and end, 0 s

Both new tests fail without this change.

#58588, #63250 and #71549 fixed the same issue and were closed before merging. #71549 set the fields inline so the batch flushes once; I used set_state to keep a single code path, and can switch to the inline version if you prefer.

closes: #58536


Was generative AI tooling used to co-author this PR?
  • Yes — Claude Code (Opus 5.5)

Generated-by: Claude Code (Opus 5.5) following the guidelines

When a Dag run hits dagrun_timeout, the scheduler skips the task that is
still running but never sets its end_date or duration, so the elapsed time
shown for it keeps growing. This test fails until the timeout path sets
both.
The timeout branch of SchedulerJobRunner._schedule_dag_run assigned
SKIPPED directly, so a task that was running kept its start_date with no
end_date or duration, and the elapsed time shown for it kept growing.
Use TaskInstance.set_state, which every other skip path goes through: it
sets end_date and duration, and gives a task that never started the same
start and end date.

@shahar1 shahar1 left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! Compared to past PRs, this one seems the cleanest and with appropriate testing.

@shahar1
shahar1 merged commit 5523443 into apache:main Oct 3, 2026
79 checks passed
@boring-cyborg

boring-cyborg Bot commented Oct 3, 2026

Copy link
Copy Markdown

Awesome work, congrats on your first merged pull request! You are invited to check our Issue Tracker for additional contributions.

@yuseok89

yuseok89 commented Oct 8, 2026

Copy link
Copy Markdown
Contributor

Thanks for fixing this! #71549 originally had this same set_state call before it was changed to an inlined update during review. Glad the simpler version is the one that landed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Task duration keeps increasing for skipped tasks due to DAG timeout

3 participants