ashb commented on code in PR #65932:
URL: https://github.com/apache/airflow/pull/65932#discussion_r4009719643
##########
airflow-core/src/airflow/models/dagrun.py:
##########
@@ -2202,6 +2202,17 @@ def schedule_tis(
debug_try_number_check = self.log.isEnabledFor(logging.DEBUG)
expected_try_number_by_ti_id: dict[UUID, tuple[int, int, str | None]]
= {}
for ti in schedulable_tis:
+ if ti.state == TaskInstanceState.UP_FOR_RETRY:
+ if TYPE_CHECKING:
+ assert ti.task
+ # Weight strategies and the mutation hook must see the
upcoming try. The updates below
+ # still own the increment, so try_number is restored.
+ try_number = ti.try_number
+ ti.try_number = try_number + 1
Review Comment:
I might have the timing/flow slight off here, but since this TI was in
`schedulable_tis`, it should mean that the retry interval has already elapsed,
and this we are _almost_ about to set the new TI.id and the try number +1.
Could you trace down what ti.id (compared to the failed "first" try) and
try_number is at this point, and when in the reschedule window this fires?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
