theJohnnyBrown opened a new pull request, #71263:
URL: https://github.com/apache/airflow/pull/71263
The Calendar view's planned-runs computation for cron timetables iterates
croniter until the year boundary with no cap, while the generic-timetable path
has always stopped at `MAX_PLANNED_RUNS` (2000). The scan runs synchronously in
the request handler on every calendar request, and the date-range filter does
not bound it (filtered dates are skipped, not stopped at).
Measured cost of the unbounded loop per `GET /ui/calendar/{dag_id}` request:
| Schedule | Iterations to year end (from early Jan) | Time |
|---|---|---|
| `*/5 * * * *` | ~104k | ~2 s |
| `* * * * *` | ~520k | ~7 s |
| `* * * * * *` (seconds cron) | ~31.5M | ~5.5 min of CPU |
Any user with Dag read access triggers this just by opening the Calendar tab
of such a Dag, which can pin an API server worker.
This applies the same `MAX_PLANNED_RUNS` cap the generic path has used since
the endpoint was added (#52748), via `itertools.islice`. Planned cells for
high-frequency crons are now shown up to 2000 runs ahead, consistent with what
an equivalent `timedelta`-scheduled Dag already does.
The new test fails without the fix (the request returns ~300k planned runs
after ~4.5 s) and passes with it; all existing calendar tests pass.
---
##### Was generative AI tooling used to co-author this PR?
- [X] Yes — Claude Code (Fable 5)
Generated-by: Claude Code (Fable 5) following [the
guidelines](https://github.com/apache/airflow/blob/main/contributing-docs/05_pull_requests.rst#gen-ai-assisted-contributions)
--
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]
