potiuk opened a new pull request, #76836:
URL: https://github.com/apache/airflow/pull/76836

   ## Why
   
   Fork CI reaches a pull request only when the scheduled monitor runs: the 
fork run is in another
   repository, so nothing in apache/airflow is triggered when it starts or 
ends. At a 15-minute
   cadence plus GitHub's scheduling delay, a fork run's start, failure or 
success showed up 10-20
   minutes late on #76536, and so did `CI run started`, which every pull 
request waits for before
   merging. When a run failed, the state comment only said "failed", so authors 
had to open the
   fork run to see which jobs broke.
   
   ## What
   
   - The fork CI monitor runs every 5 minutes. The per-run write budgets and the
     runs-before-Slack-note thresholds are derived from `MONITOR_INTERVAL`, so 
their hourly totals
     are unchanged; a test keeps it in sync with the workflow cron. Runs never 
overlap (the
     workflow's concurrency group queues one and skips further ticks).
   - The state comment of a failed fork run lists the jobs that failed, timed 
out or were cancelled
     (up to 10), each linking the job in the fork. It reuses the jobs the job 
statuses already read,
     and a read that failed is not repeated in the same run.
   
   ## Rate limits
   
   The monitor uses `GITHUB_TOKEN`, whose quota (15,000 REST calls and 10,000 
GraphQL points an
   hour) is shared by every workflow in apache/airflow. Measured on 8 monitor 
runs on 2026-11-10
   with 37 gated pull requests:
   
   | Per hour | Every 15 min | Every 5 min |
   |---|---|---|
   | Monitor REST reads | ~170 | ~500, up to ~740 with failed-job reads |
   | Writes | <= ~230 | <= ~230 (unchanged) |
   | GraphQL points | ~40 | ~120 |
   | Monitor share of the REST quota | ~2-3% | ~5% |
   
   All other workflows used up to ~4,750 REST calls in the busiest sampled 
hour, so the repository
   stays around 35% of the quota. Reads grow by about one call per gated pull 
request per run: with
   ~500 gated pull requests (fork CI for all external contributors) the monitor 
would need ~6,600
   calls an hour at this cadence, which is tight. Before that rollout the 
per-PR reads need
   batching, or the cadence goes back to 10-15 minutes. The monitor logs the 
quota it has left on
   every run and reports 30 minutes of rate limiting to Slack.
   
   Depends on #76835.
   
   related: https://lists.apache.org/thread/5603zwgpj7pgj6j979hbgpr72xsjbbws
   
   ---
   
   ##### Was generative AI tooling used to co-author this PR?
   
   - [X] Yes — Claude Code (Opus 5)
   
   Generated-by: Claude Code (Opus 5) following [the 
guidelines](https://github.com/apache/airflow/blob/main/contributing-docs/05_pull_requests.rst#gen-ai-assisted-contributions)
   
   🤖 Generated with [Claude Code](https://claude.com/claude-code)
   


-- 
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]

Reply via email to