Use latest bundle version when clearing / re-running dag#50040
Use latest bundle version when clearing / re-running dag#50040uranusjr merged 11 commits intoapache:mainfrom
Conversation
be9640d to
4bc265d
Compare
Making dag required helps me in apache#50040. It's always passed in all production code so, we can make the change. Should be thought of as private anyway. And making it kwarg only, well why not.
4bc265d to
a9d9a3b
Compare
2e5cfa9 to
4ff97f8
Compare
Right -- understandable. My thinking is that it was not intentional to make that a public function, and that I am "fixing" that in this patch release. |
The function has been around for a while(Airflow 2 or 1 not sure) and it looks like people use it in their DAGs e.g #30237 and #19329 (comment) |
|
Btw |
79ac45b to
bcaa368
Compare
When clearing a dag to be rerun, if the bundle is versioned, and bundle versioning is enabled for the dag, we should clear the bundle version (of the dag run) to be the latest bundle version seen for the dag. I removed the dag param. There's not much point in passing dag in as a param to this function since the TIs can be from different dags, so we have to look it up anyway. Moreover, they can be from different serdags associated with the same dag -- and that in particular is what makes this complicated and required me to go and use the SchedulerDagBag object.
7f19372 to
619938f
Compare
Co-authored-by: Tzu-ping Chung <uranusjr@gmail.com> (cherry picked from commit c069401)
Co-authored-by: Tzu-ping Chung <uranusjr@gmail.com> (cherry picked from commit c069401)
Use latest bundle version when clearing / re-running dag
When clearing a dag to be rerun, if the bundle is versioned, and bundle versioning is enabled for the dag, we should clear the bundle version (of the dag run) to be the latest bundle version seen for the dag.
I removed the dag param. There's not much point in passing dag in as a param to this function since the TIs can be from different dags, so we have to look it up anyway.
Moreover, they can be from different serdags associated with the same dag -- and that in particular is what makes this complicated and required me to go and use the SchedulerDagBag object.
Most of the ugliness of this PR comes from the fact that it requires that there be serialized dags which we sometimes do not create in our tests -- but which are always going to be there in production. And when I enable them in the test code, then it tends to require changes to the tests.
resolves: #49639