Repository navigation
Conversation
40f7be8 to
26897c6
Compare
0f18798 to
783542a
Compare
783542a to
cd2ebfe
Compare
cd2ebfe to
554e539
Compare
514cb98 to
592e901
Compare
|
I've merged everything in the chain that was blocking this; if you can get the migration rebased I can approve it and get it merged. |
0fb6db7 to
aa3a9ee
Compare
|
Thanks for checking the PR. |
aa3a9ee to
3882856
Compare
8f70e76 to
1ee8bb7
Compare
vincbeck
left a comment
There was a problem hiding this comment.
Just one question but overall I agree, this is the right change
ramitkataria
left a comment
There was a problem hiding this comment.
Thanks, moving this to an FK looks like the right direction but I added some questions/suggestions
234d70f to
27e5ef2
Compare
jason810496
left a comment
There was a problem hiding this comment.
Thanks for the PR for improving the execution runtime, no need to follow my suggestion directly, we might need to discuss the tradeoff.
No matter which direction we choose, we need to benchmark on the backfill to know how long will it take for both upgrade and downgrade path in case of regression when the deployments are in large-scale.
|
I benchmarked the current backfill approach, and I would prefer to keep it without a read-side fallback to Environment:
Note: During upgrade, the migration first backfills from All scenarios backfilled every callback successfully. This is a local synthetic benchmark, so production hardware, concurrent workload, replication, and real data distribution may differ. However, it suggests the payload-only worst case is a bounded, one-time upgrade cost of about six minutes at one million rows. Based on this test, I think keeping the one-time backfill and avoiding a permanent read-side fallback is a reasonable trade-off. It lets the Scheduler rely consistently on the database-managed What do you think? |
3fbff66 to
e6f19e2
Compare
e6f19e2 to
efdf231
Compare
uranusjr
left a comment
There was a problem hiding this comment.
PR description needs to be updated to mention the airflow db clean change.
efdf231 to
6aa6d2b
Compare
Why
Executor callbacks need to know which DagRun they belong to when the scheduler builds callback workloads. Keeping that reference only in
callback.datamakes the scheduler depend on payload shape instead of a database-managed relationship.Solution
Add a nullable
callback.dagrun_idforeign key todag_run.idand have executor callbacks store their DagRun reference there. The scheduler now loads the relationship through the ORM when enqueueing callback workloads.The migration backfills existing rows from deadline relationships first, then falls back to legacy callback payload data when needed. Its upgrade and downgrade paths share the callback-payload deserialization logic.
To preserve archive behavior for
airflow db clean -t dag_run, addcallbackto DagRun's dependent tables. Callback rows are then archived before their DagRun is deleted, rather than being removed by the foreign-key cascade.Was generative AI tooling used to co-author this PR?
Generated-by: [Codex] following the guidelines