Uh oh!
There was an error while loading. Please reload this page.
Fix custom timetables silently failing to schedule on Airflow 3.2 - #68326
Fix custom timetables silently failing to schedule on Airflow 3.2#68326Abdulrehman-PIAIC80387 wants to merge 3 commits into
Conversation
Congratulations on your first Pull Request and welcome to the Apache Airflow community! If you have any issues or are unsure about any anything please check our Contributors' Guide
|
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
cbdbaba to
47245e5CompareHi @jroachgolf84, thanks for the review! All comments are resolved in commit 47245e5. Any further feedback is welcome! |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Lee-W
commented
Jun 12, 2026
#68342 is closer to being merged. So I'm going to merge that first. if you're still interested in it, we can extend the test case in the the parameterization way I mentioned |
Airflow 3.2 extended
DagRunInfowith two new fields for partition-oriented scheduling (AIP-76, #61167):Both were added without defaults, making them required positional fields. Custom timetables written for 3.1.x and earlier — including the pattern shown in the official custom-timetable how-to — construct
DagRunInfowith only two arguments:On 3.2 this raises
TypeError: DagRunInfo.__new__() missing 2 required positional arguments: 'partition_date' and 'partition_key'. The exception is swallowed by the error handling aroundDAG.next_dagrun_info(), sonext_dagrun/next_dagrun_create_afterstayNULL, the Next Run column is empty, and no scheduled runs are created — with no import error or other visible failure. Built-in timetables are unaffected because they buildDagRunInfovia helpers (DagRunInfo.interval(...),DagRunInfo.exact(...), etc.) that already pass the partition fields explicitly.Fix
Default the two partition fields to
None. They are the trailing fields of theNamedTuple, so the change is purely additive and restores the documented two-argument construction. Every internal call site already passes all four fields explicitly, so their behaviour is unchanged.Design notes
NamedTuplefields is the idiomatic approach already used in this codebase — e.g.TaskInstanceKey(try_number: int = 1,map_index: int = -1). No__new__override or dataclass conversion is needed.partition_date/partition_keyexplicitly; the defaults only affect callers that omit them, which is exactly the pre-3.2 custom-timetable contract.Tests
Added two unit tests in
test_base_timetable.py: the backward-compatible two-argument construction (partition fields default toNone) and the explicit four-argument construction (partition fields still settable). Fullairflow-core/tests/unit/timetables/suite passes (220 passed).closes: #68315