Repository navigation
fix(rulesets): allow bounded hosted-runner delay in the platform merge queue #477
Description
🤖 Generated by the Agentic Engineer
Problem
The platform merge queue can discard a successfully deployed change before its final required check receives a hosted runner. The current 90-minute response limit is shorter than the observed end-to-end check arrival time.
On 5 October, platform PR #4516's merge-group run 37311681456 started at 12:44:54 UTC. Deployment succeeded at 14:08:58 UTC. GitHub evicted the entry at 14:17:47 UTC with checks_timed_out; the required aggregate succeeded at 14:35:41 UTC, 110 minutes 47 seconds after creation. That final check waited 26 minutes 37 seconds for a runner and executed for four seconds.
Intended outcome
Declare a bounded 120-minute response limit for the platform queue only. Preserve every required check, ALLGREEN, one build and merge at a time, the imported ruleset identity, its existing bypass actor, branch conditions and Observe/Update lifecycle. This is a delivery-availability mitigation, not a claim that deployments themselves are slow.
Acceptance
- A regression rejects the current 90-minute declaration and passes at 120 minutes while retaining every other queue and lifecycle invariant.
- The reviewed release is consumed and GitHub reads back the declared value without reconciliation churn.
- A subsequent genuine deployment completes its required checks and merges through the ordinary queue; platform#3097 retains its separate long-running acceptance criterion until observed.
Related: platform#3097 owns the platform timeout evidence. #475 owns the CI fan-out root cause and remains open; this change does not resolve it or remove any tests.
Activity
chore: agent-claim #477 nonce=df71194b34ca9e0c9436c032a2864b27
devantler commentedon Oct 5, 2026
PR #478 merged through ordinary repository protections at 2026-10-05T17:07:20Z, commit
dfdb8ada5d82da20b9c74b07052ffa455a3f7fda. The exact-head fallback review is a real GitHub Review and the native parser verifies it; required CI passed. The protected release run is 37346054161.Reopened after automatic PR closure because release consumption, effective GitHub readback at 120, and the subsequent ordinary production queue merge still need verification. There has been no imperative ruleset patch. Platform#3097 and #475 retain their separate acceptance criteria.
devantler commentedon Oct 5, 2026
Production readback at 2026-10-05T17:41Z confirms the declarative change is deployed:
v7.0.3is published; the source and configuration reconciliation both report Ready on that release.5275020is active and independently reports a 120-minute timeout. The other queue settings remain unchanged.No imperative ruleset patch was used. Keep this issue open until a subsequent ordinary production queue merge supplies the remaining acceptance evidence; the measured deployment-duration criteria on Platform #3097 remain separate.
devantler commentedon Oct 5, 2026
Delivered by #478 and its consumed release. Fresh GitHub and managed-resource readbacks still agree on the declared 120-minute response window, with active enforcement, ALLGREEN and the existing single-build/single-merge invariants intact. The managed resource is Ready and Synced at its current generation.
The subsequent genuine platform#4522 entered the queue after that configuration was consumed. Its protected run completed the production deployment successfully at 18:15:40 UTC, completed the required aggregate successfully at 18:27:44 UTC, and merged at 18:28:15 UTC on 5 October.
This completes this issue's bounded configuration, readback and ordinary-queue acceptance. Platform#3097 still retains its separate longer-than-90-minute acceptance, and #475 retains the CI demand root cause.