potiuk commented on issue #31687:
URL: https://github.com/apache/airflow/issues/31687#issuecomment-1621539589
cc: @uranusjr @hussein-awala .
I do not have yet the exact scenario in mind but looking at the "catchup"
fixing the problem and the code of the triggerer, I have a possible candidate.
One of the best candidates I have this use of the `_align_to_next` method as
it relies on exact equality AND the fact that it is using utcnow(). It is
executed when catchup is False, and since it is using utcnow(), I believe it
might be susceptible to behaving wrongly when you are "just before", or "just
after" or even "just at" the interval edge.
```
if restriction.catchup:
if last_automated_data_interval is not None:
next_start_time = self._get_next(last_automated_data_interval.end)
elif restriction.earliest is None:
return None # Don't know where to catch up from, give up.
else:
next_start_time = self._align_to_next(restriction.earliest)
else:
start_time_candidates = [self._align_to_next(DateTime.utcnow())] #
!!!!! <--- likely trigger of the problem
if last_automated_data_interval is not None:
start_time_candidates.append(self._get_next(last_automated_data_interval.end))
if restriction.earliest is not None:
start_time_candidates.append(self._align_to_next(restriction.earliest))
next_start_time = max(start_time_candidates)
if restriction.latest is not None and restriction.latest < next_start_time:
return None
return DagRunInfo.interval(next_start_time - self._interval,
next_start_time)
```
--
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]
