uranusjr commented on a change in pull request #19145:
URL: https://github.com/apache/airflow/pull/19145#discussion_r734197435
##########
File path: airflow/timetables/interval.py
##########
@@ -74,22 +74,22 @@ def next_dagrun_info(
earliest = restriction.earliest
if not restriction.catchup:
earliest = self._skip_to_latest(earliest)
+ elif earliest is not None:
+ earliest = self._align(earliest)
Review comment:
The previous implementation in #19130 missed this call. Without this
alignment call, the next run's data interval would start at the current time
(e.g. 2021-10-22T10:43:57.43256) instead of the interval boundary (e.g.
2021-10-22T10:00:00.00000) and cause inconsistencies. So I moved the call here
to make sure it is always done correctly.
##########
File path: airflow/timetables/interval.py
##########
@@ -205,14 +205,14 @@ def _skip_to_latest(self, earliest: Optional[DateTime])
-> DateTime:
This is slightly different from the delta version at terminal values.
If the next schedule should start *right now*, we want the data
interval
- that start right now now, not the one that ends now.
+ that start now, not the one that ends now.
"""
current_time = DateTime.utcnow()
- next_start = self._get_next(current_time)
last_start = self._get_prev(current_time)
Review comment:
The previous implementation
```python
next_start = self._get_next(current_time)
last_start = self._get_prev(current_time)
```
had a bug if `current_time` falls right on the interval boundary (e.g. the
full hour mark for a `@hourly` schedule interval) because `croniter` would make
`next_start` and `last_start` _two_ hours apart instead of one. So this is
changed to
```python
last_start = self._get_prev(current_time)
next_start = self._get_next(last_start)
```
toe ensure the two starts are one hour apart, and `current_time ==
next_start` for the interval boundary case. This is not really practically
relevant (what's the change a `now()` calls falls directly one that time with
microsecond accurary), but is an issue in unit tests.
--
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]