perf(canary): date-bound the per-role run list to one 15-day tier (#1259 option B)
Refs #1259. Does not close it: the effect is unmeasured until a scheduled sweep runs on this.
Why
After the shared run-list cache (#1271), the residual cost of promote-all (~15.5 min) is ~99% gh run list -L 1000 on the legacy per-role path. The gate only samples windows that start at most ~2 weeks back, so most of those 1000 runs on a busy workflow are dead weight.
What
_agent_run_json (legacy per-role path) now reads one date-bounded list:
- New
_horizon_from <since> <tiers>holds the tier math and sets_HORIZON_FROM._ingress_horizonis now a thin wrapper over it, so the ingress path behaves as before. - The per-role read uses a single 15-day tier (
CANARY_RUNS_HORIZON_TIERS, default15) via--created >=YYYY-MM-DD. - GitHub caps
createdlistings at 1000 and returns them newest-first, so a bounded list that fills the cap is the newest 1000. It is used as is, with no refetch. - A window older than the tier, or an empty window, keeps the unbounded read. An empty tier list disables bounding.
- Truncation behavior at 1000 is unchanged. The separate observation that a capped legacy list is not failed closed is out of scope here.
Existing test deliberately changed (please look at this)
the ingress run list is date-bounded for a recent window and unbounded for an old or empty one (#1259) previously asserted "per-role workflow lookup is NOT date-bounded". That is exactly what this change reverses, so the assertion is flipped to expect --created >=$(date -u -d '-15 days' +%Y-%m-%d) on the per-role lookup. No other assertion was altered.
Tests
- 5 new "option B" tests: bound applied for a recent window; unbounded for an older window; unbounded for an empty window; a list that fills the cap is used without a second read; tiers disabled by an empty setting.
- Canary suite 474/474 in default mode and with
CANARY_PRELOAD_REGISTRY=1;test/scripts/standards-templates11/11;shellcheck --severity=warningclean. - Run with
GITHUB_REPOSITORY=petry-projects/.github, as CI sets it. Without it the script'sTHIS_REPOdefault (.github-private) sends the orchestrator tests down the local-git path and ~64 fail spuriously. That is an environment issue, not a code issue.
Expected benefit
Workload-dependent: quiet repos should see roughly 2-4x faster per call; hot repos with >1000 runs in 15 days gain nothing. After merge I will read the next scheduled sweep's canary timing [promote-all] line and report on #1259 before proposing any change to the 60-minute timeout.
Rollback
Revert this PR, or set CANARY_RUNS_HORIZON_TIERS="" to disable the bound without a revert.
🤖 Generated with Claude Code
https://claude.ai/code/session_01MjXPsBTaL6WV9AhCH2ajuv
Generated by Claude Code