Don't re-emit logical_date when previous data_interval is zero-length

[jedcunningham]

What's the bug

_DataIntervalTimetable.next_dagrun_info aligns the next run's start onto data_interval.end of the previous run. When that previous interval is zero-length (start == end), start lands on the same point as the existing run's logical_date, so the scheduler tries to create a run that collides with the existing one and logs:

run already exists; skipping dagrun creation

It then calls calculate_dagrun_date_fields(last_automated_run=existing_run) to advance — which feeds the same zero-length interval back in and recomputes the same value. The scheduler loops on the skip warning until the next cron boundary nudges _skip_to_latest to a different result, at which point the gate may have already rolled past the slot — so the intended run is silently skipped.

When does this happen?

Zero-length data_intervals are the normal output of CronTriggerTimetable (point-in-time) but never of CronDataIntervalTimetable (windowed, validated > 0). They appear on a CronDataIntervalTimetable DAG when its scheduling history was produced by CronTriggerTimetable and the DAG later switches to CronDataIntervalTimetable — for example, when [scheduler] create_cron_data_intervals is flipped from False (Airflow 3 default) to True after some runs have already been created.

The fix

In _DataIntervalTimetable.next_dagrun_info, after computing start, if the previous interval was zero-length and start falls on it, advance start by one period so the new run gets a fresh logical_date.

The guard only fires for _DataIntervalTimetable subclasses (CronDataIntervalTimetable, DeltaDataIntervalTimetable). CronTriggerTimetable / DeltaTriggerTimetable extend a separate _TriggerTimetable base with its own next_dagrun_info and never go through this code path, so their normal zero-length output is unaffected.

Tests

Added test_zero_length_last_interval_does_not_re_emit_logical_date parametrized on catchup ∈ {True, False} — both branches converge on the same expected interval, demonstrating the guard absorbs the difference between the two paths into the previous-run handling.

related: #59618

Was generative AI tooling used to co-author this PR?

• Yes — Claude Code (Anthropic)

[Lee-W]

Overall, looks good, but will need to take a look at the failed tests

[github-actions]

Backport successfully created: v3-2-test

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
✅	v3-2-test

[jedcunningham]

And just for posterity, why formalizing this is better than blowing errors through the whole overlapping period? Well, if you have more dags in this scenario than max_dagruns_to_create_per_loop (which is likely if you've toggled create_cron_data_intervals), then you get no runs scheduled at all.