Conversation
o-nikolas
left a comment
There was a problem hiding this comment.
One could argue that this is a breaking change since the operator will now exhibit a different behaviour than before (Dags may take longer than they usually do). But I think this fits as bug fix since before the timeout needed to be increased otherwise the operation wouldn't have succeeded anyway, which is the ultimate goal.
That merits a warning note at the top of the changelog so can be added to the bugfix release. |
Classifier training sometimes takes longer than 20 minutes, but the operator's default waiter budget was 20 x 60s in both sync and deferrable paths, so those runs failed with a waiter timeout. Raise the cap to 60 x 60s: the companion sensor and trigger allow 150 minutes, but that is too large a jump for the operator's implicit wait, so they are left unchanged. This also lets the system test Dag drop its wait_for_completion=False workaround, so the test exercises the operator's default wait path. A changelog warning documents the longer default wait.
1593171 to
3b54a66
Compare
…apache#71969) Classifier training sometimes takes longer than 20 minutes, but the operator's default waiter budget was 20 x 60s in both sync and deferrable paths, so those runs failed with a waiter timeout. Raise the cap to 60 x 60s: the companion sensor and trigger allow 150 minutes, but that is too large a jump for the operator's implicit wait, so they are left unchanged. This also lets the system test Dag drop its wait_for_completion=False workaround, so the test exercises the operator's default wait path. A changelog warning documents the longer default wait.
Classifier training routinely takes 8 to 20+ minutes, but the operator's default waiter budget was 20 x 60s in both sync and deferrable paths, a cap the training time sometimes exceeded. Triple it to 40 x 60s. (The companion sensor and trigger allow 75 x 120s, but jumping the operator's implicit wait to 150 minutes would block Dag runs unexpectedly long, so they are intentionally left as is.) This also lets the system test Dag drop its wait_for_completion=False workaround, so the test exercises the operator's default wait path.
Was generative AI tooling used to co-author this PR?
{pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.