avanish-garg commented on issue #72427:
URL: https://github.com/apache/airflow/issues/72427#issuecomment-5868281948
Dug into this further and I think this is actually working as intended, not
a bug —
closing based on my own finding, per the "if it's intentional, this issue
should probably
just be closed" note in the original report.
The exact mechanism here (`_skip_to_latest` calling
`_align_to_next(earliest)`, which
bumps the schedule forward to the next period boundary at/after
`start_date`) was
deliberately introduced in #21011 ("Fix the incorrect scheduling time for
the first run of
dag") to enforce a real invariant: **a DAG run's data interval must never
start before the
DAG's `start_date`**. That PR's own regression test
(`test_no_catchup_first_starts_at_current_time` in
`test_interval_timetable.py`) encodes
exactly this — when `start_date` falls mid-period, the first run is
deliberately bumped
past that period rather than allowed to use one that started before the DAG
existed.
The scenario I reported (`start_date` a few hours ago, today) hits the
identical rule, not
a separate case: whether `start_date` lands inside an already-completed
period or inside
the currently-in-progress one, the underlying question is the same — did
part of that
period elapse before the DAG existed? In both cases the answer is yes, so
both get bumped
forward by the same logic. There's no principled way to special-case
"currently in
progress" without reopening the exact backdating bug #21011 fixed.
So the "~2 periods" delay in my repro is the correct, intended consequence
of that
existing fix, not a new defect. Apologies for the noise — closing this out.
--
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]
