ferruzzi commented on code in PR #70167:
URL: https://github.com/apache/airflow/pull/70167#discussion_r3626491463
##########
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:
Something isn't adding up. If you check out the unit test
`test_daily_cron_trigger_no_catchup_first_starts_at_next_schedule`
(specifically the `first-run` case)
[here](https://github.com/apache/airflow/blob/063d5f108dad0ff0167814e65899aa7b95bd8f12/airflow-core/tests/unit/timetables/test_trigger_timetable.py#L78)
it seems to be testing this and asserting the opposite. Any chance you are
using out of date docs to update out of date docs? LOL Have a look at the
test, maybe I'm just mis-reading it.
--
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]
