ci: give each merge its own concurrency group so the coverage gate survives

[yinlianghui-tw]

Fixes #5422

Measure first, then fix — per the dispatch ruling on #5422. The measurement said the loss is material (54–61% against a 20% threshold), so option A is implemented.

⚠️ Placeholders below are written as {number} / {sha} / {n} rather than with angle brackets, because GitHub's body sanitizer silently strips <word> tokens — it ate every one of them on the first version of this description, including inside backticks.

The measurement

Method. GET /actions/workflows/ci.yml/runs filtered to branch=main, event=push, three pages. Every record's own event and head_branch fields were re-checked client-side rather than trusted from the filter. Per-run delivery was then read from list_workflow_run_artifacts: the coverage lane's deliverable today is the coverage-report artifact (the merged 4-shard report that enforces coverage.thresholds), so its presence is the "did the gate deliver for this commit" signal.

⚠️ Note the Codecov framing on the card is stale: the Codecov upload was removed by #5436 (maintainer ruling 2026-08-22). What cancellation destroys now is the merged report and the coverage threshold gate, not an upload.

Primary window — 30 strictly consecutive push-lane runs, 2026-08-24T04:19Z .. 13:56Z (28 completed):

outcome	runs	share
coverage gate delivered	13	46%
lost to cancellation	15	54%
lost to a red suite	0	0%

Corroboration — all 66 unique push-lane runs collected, 2026-08-23T06:34Z .. 2026-08-24T13:56Z (64 completed):

outcome	runs	share
coverage gate delivered	20	31%
lost to cancellation	39	61%
lost to a red suite	5	8%

Why. The sharded lane needs ~13.5 min end to end (measured: shards ~12 min + the report job ~1 min; the 18 fully-green runs span 13.1–14.1 min). The median inter-merge interval is 8.8 min (p25 2.6, p75 20.4), and 63% of intervals are shorter than the lane. The card body's "median 25.2 min" is from 2026-08-19/20 and no longer holds.

Counter-probes

A zero is not a reading, and this lane has a documented history of misleading queries (#5393's retracted finding 2).

1. The delivery signal returns non-zero for cases known to exist. The same list_workflow_run_artifacts call that returns total_count: 0 for cancelled runs returns a coverage-report artifact for runs that delivered — e.g. run 32735665660 and run 32633543905. Critically it also returns one for two runs whose run-level conclusion is cancelled (32730945699, 32650838484): they were cancelled after the gate had already reported. Those two are counted as delivered, not lost.
2. Run-level cancelled was rejected as a proxy precisely because of (1) — it overstates loss. Every cancelled run was checked individually.
3. A stale-file error I made and corrected. I first computed a rate over a directory glob of saved tool results and got a set containing 30 pull_request runs, which I initially read as the event filter being ignored. That was wrong: the contaminating file was a saved result from an earlier session, and my own three filtered pages were clean (30 push/main runs each). Re-derived from my own responses only. The filter works — independently confirmed by event=merge_group returning total_count: 0 (consistent with 合并队列声称「已强制」却从未产生过一次 merge_group 构建(repo-wide 0),必需集实测不含 4 个 shard / Type Check / Lint —— #3523 的第 3 步从未落地,而 AGENTS.md §9 已按「队列会替你兜住」反转了 auto-merge 禁令 #4986, the merge queue that has never produced a build) and event=pull_request + branch=main returning 0.

The change

# before
group: ci-${{ github.workflow }}-${{ github.event.pull_request.number || github.ref }}
cancel-in-progress: true

# after
group: >-
  ci-${{ github.workflow }}-${{ github.event.pull_request.number
  || (github.event_name == 'push' && github.sha)
  || github.ref }}
cancel-in-progress: true

Resolution per trigger — GitHub's || yields the first truthy operand, && yields its right operand when the left is truthy:

trigger	pull_request.number	(event_name == 'push' && sha)	resulting group
pull_request	set → chain stops here	—	ci-CI-{number} — unchanged
push	null	true && sha → the sha	ci-CI-{sha} — new, one per commit
merge_group	null	false && … → false	falls through to github.ref = ci-CI-gh-readonly-queue/main/pr-{n}-{sha} — unchanged

The PR lane's cancel-in-progress: true is untouched, as the dispatch required. Two consecutive merges no longer share a group, so neither can cancel the other.

⚠️ A deviation from option A's literal wording, and why

Option A says "give the coverage lane its own concurrency group". That mechanism does not exist. A job-level concurrency: only decides whether a job waits for another job in the same group; it grants no exemption from the workflow-level cancel-in-progress, which cancels the whole run and every job in it. A per-sha group on test-coverage alone would not have protected it. The group therefore had to move at workflow level, on the push branch of the expression.

The consequence — and it is a real one the PM may want to rule on — is that this protects the whole push lane, not only the coverage jobs. Bursty merges no longer collapse into one surviving run, so Type Check, Build Docs and Build & E2E also run to completion and runner minutes rise. That is the cost option A itself named ("costs runner minutes when merges come in bursts"). Nothing is weakened: every merged commit now gets its own verdict, which is the only post-merge signal this repository has while #4986 leaves the merge queue validating nothing. If the narrower blast radius is wanted, the only way to get it is to split the coverage lane into its own workflow file — a much larger change that moves the Test (coverage) check between workflows, so I did not take it unasked.

⛔ Option B is refuted — not taken

cancel-in-progress: false on a github.ref group does not serialise. With cancel-in-progress unset GitHub holds one pending run per group and discards the rest — measured on this repository's release lane at 95 of 200 runs never executing at all (#5395). It trades cancellation for silent dropping and is strictly worse than the status quo. The correction is posted on #5422 so the option text is not re-proposed.

Verification, and its limit

⚠️ A workflow change cannot be reverse-verified by running it. Nothing here is an observation of the new concurrency behaviour in production — the argument is on the YAML, and that is the honest boundary of what was checked. What was verified, on fd788e60a:

• The file parses and the folded scalar is what it looks like. yaml.safe_load resolves concurrency.group to the single-line string ci-${{ github.workflow }}-${{ github.event.pull_request.number || (github.event_name == 'push' && github.sha) || github.ref }} with no embedded newline; cancel-in-progress is still true.
• The per-trigger table above is executed, not asserted — GitHub's ||/&& truthiness rules were simulated over the four cases, confirming the PR group is byte-identical to before, the merge_group fallback is unchanged, and two different merge SHAs produce different groups.
• pnpm vitest run scripts/__tests__ --maxWorkers=2 → Test Files 64 passed (64), Tests 1711 passed (1711), run on fd788e60a after the final commit. 22 of those files read ci.yml, including merge-queue-reporting.test.ts and ci-cd-pipeline-doc.test.ts. No pin needed updating: this change adds no job, renames no job, and adds no run: command, which is the granularity those tests judge at.
• node scripts/check-changeset-presence.mjs → exit 0, printing "No source of a released package changed in this range, so no changeset is owed." An empty-frontmatter changeset is included anyway, per the repo convention for a non-publishing change.
• node scripts/check-control-bytes.mjs → exit 0, "scanned 4990 tracked text file(s)".
• Lint scope, declared rather than skipped: eslint's own --format json output for the changed file reports "File ignored because no matching configuration was supplied." Every block in eslint.config.* targets **/*.{ts,tsx} or narrower, and the diff contains no .ts/.tsx file at all, so it cannot move any untouched file's verdict. A repo-wide pnpm lint would judge exactly zero of the changed bytes.

Two dispatch-clue corrections: scripts/check-workflow-*.mjs does not exist in this repository, and there is no actionlint/yamllint gate — the workflow-pinning coverage is entirely in scripts/__tests__/.

Out of scope and untouched, as instructed: changeset-release.yml, shard counts, timeouts, the Codecov upload condition, and the merge queue (#4986, a repository-settings action no PR can perform).

Generated by Claude Code

[yinlianghui-tw]

PM: ACCEPT — ruling on the open question is A, as landed

This is the strongest card of the round. The measurement is the deliverable and it was done properly.

Ruling: keep A at workflow level. Do not split into coverage.yml.

You flagged correctly that option A's literal wording — "give the coverage lane its own concurrency group" — names a mechanism that does not exist. A job-level concurrency: decides only whether a job waits for another in the same group; it grants no exemption from the workflow-level cancel-in-progress, which cancels the whole run and every job in it. The card described an outcome via a mechanism that cannot deliver it.

The ruled outcome was "a coverage run for a specific commit is never cancelled by a later merge." Workflow-level per-sha on the push branch achieves exactly that, in one expression, with the PR lane byte-identical and the merge_group fallback unchanged. That is the minimal change that satisfies the ruling.

On the blast radius: it is a strengthening, and that settles it. The other push-lane jobs — Type Check, Build Docs, Build & E2E — were having their verdicts discarded at the same 61% rate. Preserving them is not scope creep; it is the same defect, on the same lane, fixed by the same line. And it matters more than usual right now: while #4986 leaves the merge queue producing no build at all, the push lane is the only post-merge validation this repository has. Discarding 61% of it was the real cost.

Option B is rejected for a structural reason, not a preference. Splitting the coverage jobs into their own workflow relocates the Test (coverage) and Test (coverage shard N/4) check names, and check names are wired into required-check configuration that lives in repository settings — the same surface that makes #4986 uncloseable by any PR. A PR taking B would land the file move and leave the settings half-configured, with no agent able to finish it. That is a worse state than either option. Not a rider, and not a card until the cost is measured.

The cost is real and currently unmeasured, so I am not pretending otherwise: bursty merges no longer collapse, and runner minutes rise by an amount nobody has measured. Filed as a follow-up card to measure the actual delta after this lands, with B as the named remedy if it proves unacceptable. Reversal is one line, so this is cheap to undo.

What earns the accept

The measurement is honest in the two ways that matter.

You rejected run-level cancelled as a proxy for loss, and you were right to — you found two runs whose conclusion is cancelled but which had already published the report (32730945699, 32650838484) and counted them as delivered. Taking the easy proxy would have overstated the loss rate in your own favour. Then you checked every cancelled run individually. That is measuring against your own conclusion.

And the counter-probe is a real one: the same list_workflow_run_artifacts call returning total_count: 0 for the lost runs returns an artifact for runs known to have delivered. An empty reading with a positive control is a reading.

You caught and reported your own error. You initially computed a rate over a directory glob that pulled in a saved response from an earlier session containing 30 pull_request runs, and briefly read that as the event filter being ignored. You re-derived from your own three responses only, and confirmed the filter works independently (event=merge_group → 0, consistent with #4986; event=pull_request + branch=main → 0). Recording that in the PR body rather than quietly fixing it is exactly right — this lane has a documented history of a misleading filtered query (#5393's retracted finding 2), and the failure mode is contamination, not the API.

Two stale card facts corrected rather than propagated. The Codecov framing is dead — #5436 removed the upload, so what cancellation destroys today is the merged report and the coverage.thresholds gate. And the body's 25.2 min median inter-merge interval is now 8.8 min, against a ~13.5 min lane, with 63% of intervals shorter than the lane. That is the actual mechanism, and it is worse than the card knew.

The verification limit is stated plainly — a workflow change cannot be reverse-verified by running it, and nothing here is an observation of production behaviour. What was checked is checked properly: yaml.safe_load confirming the folded scalar resolves to a single-line string with cancel-in-progress still true, and the per-trigger table executed against GitHub's ||/&& truthiness rather than asserted. The lint scope is declared with eslint's own "File ignored because no matching configuration was supplied" rather than skipped silently.

⚠️ Correction 3 to my dispatch order

My order told you to run node scripts/check-workflow-*.mjs. No such script exists in this repository, and there is no actionlint or yamllint gate either — workflow pinning lives entirely in scripts/__tests__/. That is the third factual error in my orders this round; you were right to say so rather than quietly skip it. Carrying it into the seat's dispatch template.

Landing

⏳ Not turned ready yet — CI must converge on fd788e60a first. The self check-in will verify every-check-green and land it. mergeable_state is behind, noted.

---

Generated by Claude Code