The macOS check job exceeds the merge queue's 30-minute cap once the cli lane's worked-example tests land: on PR #728 (integration head d850f06f) run 36262653588 was cancelled at 30.3 minutes while internal/surface/cli was still running under the race lane, where main's macOS runs take 23 to 28.5 minutes. The job's timeout-minutes equals the queue's check_response_timeout, so the queue fails the group rather than waiting. The cli package's test wall time, above all under -race, is the lever: it must come down by at least the three minutes the leg is over without weakening what the tests prove.

Frontmatter

.abcd/work/issues/resolved/iss-2609261924541555-the-macos-check-job-exceeds-the-merge.md
open on GitHub ↗ · commit history ↗

mentions2

• dcn-26092800000000012026-09-28 — Rulings Z, AR and the cancel policy, given by the user as technical facilitator at 15:10:37Z (autonomous run A, recorded by lane cap45 for orchestrator abcd-a8). (Z) The macOS leg of ci.yml's `check` job and the main ruleset's merge-queue `check_response_timeout_minutes` both rise from 30 to 45 minutes, because a 30-minute cap cancelled passing macOS runs (#728, #730 twice, #733; iss-2609281514435020). This amends the standing rule that never raises the check job's timeout or edits the ruleset, for exactly this one change: 45 minutes, those two settings; every other timeout, every required-check name or split and every other ruleset field stays as it is, and the ubuntu leg keeps 30. The workflow and the `.abcd/work/rulesets/main-protection.json` mirror change through a reviewed pull request; the live ruleset is changed with `gh api` by the run's orchestrator after that pull request merges, and until then the live queue still fails a group at 30 minutes. (AR) All three speed-ups of iss-2609261924541555 are built: a test-only switch that skips the disk flush in the atomic write code and the slowest -race package first in the race step (lane ciSpeed), and the scanner's per-identity git calls folded into one (lane scanFold), a trust path that is security-reviewed before it lands. (Cancel policy) The rerun-once rule stands: a check cancelled at the cap is rerun once, and a second cancellation for the same reason stops that pull request and opens a speed lane, never another raise of the timeout; and a step on the macOS leg warns, in the log and the step summary, once the check has run past 35 minutes, without ever failing the job, so a speed lane opens before any cancellation.
• iss-2609261943168303recordid's filename grammar compiles a fresh regexp on every call: idRe (behind FilenameNumRe) runs regexp.MustCompile each time, and both per-file readers call it once per record file, the resolver's fileID in internal/core/recordid/resolve.go and peers' fileID in internal/core/peers/read.go. Every resolver scan and every peers scan, which the bare board runs on each render, therefore recompiles the same pattern once per record in the checkout: 29% of the CPU of the bare-board tests in internal/surface/cli, and several times that under -race, where it inflates the macOS check leg that iss-2609261924541555 records running past the merge queue's cap. The grammar is a pure function of a fixed family prefix, so one compiled pattern per prefix answers identically.