ci: preserve routing App quota during hosted queue rescue
The scheduled hosted-light rescue was spending the routing App installation quota to list runs and jobs, even though its job token already has the actions scope required by the sweep. Use that workflow token for reads as well as cancellation and reruns, leaving the shared installation budget for routing operations.
Leo asked: “how’s CI? we still have bigger wins we can get? what’s the state of it all? more things we can skip/do better”. This is the quota slice of the queue repair. The pinned rescue already falls back to the fresh run’s PR head when the workflow token cannot read pull requests (#32120). Revert this change to restore the previous read-token choice.
| Performance metric | Before | After | Delta | Harness |
|---|---|---|---|---|
| Routing App REST reads per empty rescue sweep | 12 | 0 | −100% | Same pinned rescue and declared workflow set, empty run listings; only workflow token selection differs |
This moves those 12 reads to the per-repository workflow budget; it does not remove the requests. Runs with candidates save their job/head reads from the App budget too. This job compiles nothing, so build caches do not apply.
Validation: python3 tests/test_ci_runner_pools.py passed all 42 tests on the build fleet at 99753ed68f9375835e9a370824eb4c221941105b (job ad94be4dd5c96de8ae7e8711). Independent Astra high review: SHIP at the same head.
Observed / Not run
The same-harness token-budget comparison and focused fleet tests passed. The scheduled rescue has not yet run with this token selection. The initial Actions check did not start and was cancelled by its supported fallback; its fleet submission was reconciled before retrying.
Changelog
none
Prior art: #32023, #32120 and main activation #32061; #34200 keeps the App-key watcher on its existing ephemeral selector. Overlapping old branches #26585 and #11285 predate the rescue step and do not implement this change.
🤖 Generated with Codex
Agent session: agent session