Tegh25 commented on code in PR #70167:
URL: https://github.com/apache/airflow/pull/70167#discussion_r3632173923
##########
airflow-core/docs/core-concepts/dag-run.rst:
##########
@@ -138,20 +150,30 @@ then you will want to turn catchup off, which is the
default setting or can be d
)
In the example above, if the Dag is picked up by the scheduler daemon on
-2016-01-02 at 6 AM, (or from the command line), a single Dag Run will be
created
-with a data between 2016-01-01 and 2016-01-02, and the next one will be created
-just after midnight on the morning of 2016-01-03 with a data interval between
-2016-01-02 and 2016-01-03.
-
-Be aware that using a ``datetime.timedelta`` object as schedule can lead to a
different behavior.
-In such a case, the single Dag Run created will cover data between 2016-01-01
06:00 and
-2016-01-02 06:00 (one schedule interval ending now). For a more detailed
description of the
-differences between a cron and a delta based schedule, take a look at the
-:ref:`timetables comparison <Differences between the cron and delta data
interval timetables>`
-
-If the ``dag.catchup`` value had been ``True`` instead, the scheduler would
have created a Dag Run
-for each completed interval between 2015-12-01 and 2016-01-02 (but not yet one
for 2016-01-02,
-as that interval hasn't completed) and the scheduler will execute them
sequentially.
+2016-01-02 at 6 AM (or from the command line), with the Airflow 3 default of
+:ref:`CronTriggerTimetable` for ``@daily`` and ``catchup=False``, the scheduler
+does **not** create a run for the past midnight. The next Dag run is created at
+midnight on the morning of 2016-01-03, with ``data_interval_start`` and
+``data_interval_end`` both equal to that trigger time.
+
Review Comment:
It seems like you're right and those lines are wrong for the example as
written.
I had misread the first-run path. Because the tutorial Dag sets
``start_date``, ``TimeRestriction.earliest`` is also set. Therefore,
``catchup=False`` uses ``max(_align_to_prev(now), _align_to_next(earliest))``
and does **not** call ``_calc_first_run()`` (that's only when ``earliest is
None``). This is indicated by the [catchup logic
here](https://github.com/apache/airflow/blob/main/airflow-core/src/airflow/timetables/trigger.py#L97-L106).
In the example: Picked up at 2016-01-02 06:00 with ``@daily``, that means
the first run is **2016-01-02 00:00** (the most recent past tick), not
2016-01-03. Same idea as
``test_daily_cron_trigger_no_catchup_first_starts_at_next_schedule`` with
``id="first-run"``, as you pointed out.
I'll fix the example explanation to say the scheduler creates a run for that
morning's midnight (zero-width interval), and only later ticks wait for their
schedule time. Thanks for the catch.
Although this logic in the code makes sense, from the perspective of a user
of Airflow, this behavior for ``catchup=False`` seems unintuitive to me. I'd
welcome anyone else to chime in on this conversation.
--
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]
