Skip to content

[v3-3-test] Fail task instances whose stored next_kwargs cannot be processed (#70685) - #71183

Merged
vatsrahul1001 merged 1 commit into
v3-3-testfrom
cherry-pick-70685-v3-3-test
Aug 5, 2026
Merged

vatsrahul1001 merged 1 commit into
v3-3-testfrom
cherry-pick-70685-v3-3-test

Conversation

@vatsrahul1001

Copy link
Copy Markdown
Contributor

Backport of #70685 to v3-3-test for the 3.3.1 patch release — this was missed (the main PR merged but no backport was raised).

A deferred task whose stored next_kwargs can't be deserialized/processed was left stranded rather than failed. This routes it through the normal failure path (and the scheduler's awaiting-input timeout sweep survives such task instances instead of crashing).

Cherry-picked with -x from 2b7a0be359. Applied cleanly — git auto-merged the test_trigger.py imports where this and the already-backported #69821 (#71163) both add imports. The full test_trigger.py suite (plus the new scheduler test) passes on v3-3-test — 42 tests green.

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

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

)

* Fail task instances whose stored next_kwargs cannot be processed

handle_event_submit decoded a task instance's stored next_kwargs and assumed
the result was a dict. Neither assumption held: the decode caught only four
exception types, so anything the BaseSerialization fallback raised escaped,
and the isinstance check sat under TYPE_CHECKING, so it never ran at runtime.

Both escape as exceptions from a function whose callers walk every waiting
task instance in one pass — the scheduler's timeout sweep and two API routes
— so a single unusable payload aborted the whole batch.

Decode through a helper that checks its result, and guard decode, event
insertion and re-encode together. A task instance whose payload cannot be
processed is re-queued to fail through the existing __fail__ path, so its
normal retry and callback handling still runs, instead of being left parked
for the next sweep to trip over again.

Generated-by: Claude Opus 5 (1M context) following the guidelines at
https://github.com/apache/airflow/blob/main/contributing-docs/05_pull_requests.rst#gen-ai-assisted-contributions

* Report why a task instance could not be resumed, and to whom

The Dag author sees only the task log, so the traceback has to travel in
next_kwargs the way submit_failure already sends it; the process log where this
runs is often not theirs to read.

Decode and re-encode also fail for different reasons: blaming the stored kwargs
for a payload the trigger just yielded points the author at database state that
was never at fault. The sweep's summary counted an unresumable task as resolved.

* Update airflow-core/src/airflow/models/trigger.py

Co-authored-by: Amogh Desai <amoghrajesh1999@gmail.com>

* Fix ruff D205/D213 on _fail_unresumable_task_instance docstring

One-line summary on the second line + blank line before the description, so the docstring
satisfies both D205 (blank between summary and description) and D213 (summary on second line).
Static checks were failing on ruff for this.

---------

Co-authored-by: Amogh Desai <amoghrajesh1999@gmail.com>
Co-authored-by: Rahul Vats <rah.sharma11@gmail.com>
(cherry picked from commit 2b7a0be)
@vatsrahul1001
vatsrahul1001 merged commit 9b6d80b into v3-3-test Aug 5, 2026
75 checks passed
@vatsrahul1001
vatsrahul1001 deleted the cherry-pick-70685-v3-3-test branch August 5, 2026 15:14
vatsrahul1001 added a commit that referenced this pull request Aug 5, 2026
) (#71183)

* Fail task instances whose stored next_kwargs cannot be processed

handle_event_submit decoded a task instance's stored next_kwargs and assumed
the result was a dict. Neither assumption held: the decode caught only four
exception types, so anything the BaseSerialization fallback raised escaped,
and the isinstance check sat under TYPE_CHECKING, so it never ran at runtime.

Both escape as exceptions from a function whose callers walk every waiting
task instance in one pass — the scheduler's timeout sweep and two API routes
— so a single unusable payload aborted the whole batch.

Decode through a helper that checks its result, and guard decode, event
insertion and re-encode together. A task instance whose payload cannot be
processed is re-queued to fail through the existing __fail__ path, so its
normal retry and callback handling still runs, instead of being left parked
for the next sweep to trip over again.

Generated-by: Claude Opus 5 (1M context) following the guidelines at
https://github.com/apache/airflow/blob/main/contributing-docs/05_pull_requests.rst#gen-ai-assisted-contributions

* Report why a task instance could not be resumed, and to whom

The Dag author sees only the task log, so the traceback has to travel in
next_kwargs the way submit_failure already sends it; the process log where this
runs is often not theirs to read.

Decode and re-encode also fail for different reasons: blaming the stored kwargs
for a payload the trigger just yielded points the author at database state that
was never at fault. The sweep's summary counted an unresumable task as resolved.

* Update airflow-core/src/airflow/models/trigger.py



* Fix ruff D205/D213 on _fail_unresumable_task_instance docstring

One-line summary on the second line + blank line before the description, so the docstring
satisfies both D205 (blank between summary and description) and D213 (summary on second line).
Static checks were failing on ruff for this.

---------



(cherry picked from commit 2b7a0be)

Co-authored-by: Jarek Potiuk <jarek@potiuk.com>
Co-authored-by: Amogh Desai <amoghrajesh1999@gmail.com>
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.

3 participants