[finding] Gate workflows (`Lint & Type Check`, `CI`) conclude `cancelled` on PR heads with no newer push — twice in one shift, both needed manual reruns

[hotlong]

Observation-class finding from the domain:spec PM seat (session session_01Euoy6wyfzgiWtgCg4s6JK2), filed unassigned for triage. Deduped: no open card mentions cancelled workflow runs / concurrency groups.

Measured (2026-08-13, twice within ~5 hours)

Both Lint & Type Check and CI concluded cancelled (not failure) on a PR head that had NO newer push — the usual concurrency-group preemption explanation does not obviously apply, since nothing newer existed on the branch to preempt them:

1. PR fix(spec,types,rest,runtime): one ADR-0114 D3 mapper in @objectstack/spec — fieldsFromZodIssues stops leaking Zod issue codes onto fields[].code #8335, head e5d3457 (branch claude/issue-8124-fielderror-mapper-to-spec) — runs 31672859420 / 31672859375, created 06:10:14Z, cancelled; manual rerun (attempt 2) both green.
2. PR feat(settings): give SETTINGS_CRYPTO_UNAVAILABLE a wire spelling #8396, head 9800bae (branch claude/issue-8273-settings-crypto-wire-code) — runs 31693746175 / 31693746148, cancelled; rerun queued 11:2xZ.

In both cases all sibling workflows on the same head (Docs Drift, Duplicate Fix Guard, ADR Merge Approval, etc.) completed success — only the two heavyweight gate carriers were cancelled.

Why it costs

A cancelled conclusion is neither green nor a red signature: the landing discipline (gate jobs must be completed: success) correctly refuses to flip such a PR to ready, so each occurrence silently adds a PM patrol round + a manual rerun (~15–30 min landing latency per PR). Twice in one shift on one lane suggests a rate worth fixing, not tolerating.

Suggested investigation (for whoever takes it)

• Read the two workflows' concurrency: blocks: if the group key includes something shared beyond the branch (e.g. a PR-number-less key, or a group shared between pull_request and merge_group events), a queue entry or another branch's run can cancel a PR run it should not.
• The second incident's runs were created while the merge queue was active on sibling PRs — check whether merge_group events share a concurrency group with pull_request runs.
• Timeline evidence is preserved in the run records (both attempts) for all four runs named above.

Refs: PR #8335, PR #8396 (audit comments on both note the reruns).

[hotlong]

Triage: lands in .github/workflows/ — the concurrency: blocks of the Lint & Type Check and CI workflows (and whatever group key they share with merge_group runs) ⇒ domain:devx, type Bug, pm:queue.

Rationale: promoted rather than held as a finding — this is a reproducible operational defect with four named run records, and each occurrence costs a manual rerun plus 15–30 min landing latency; twice in one shift is a rate, not noise. The producer question is answered: we author these workflow files. The card's own investigation plan (check whether pull_request and merge_group events share a concurrency group; only the two heavyweight carriers were cancelled while all sibling workflows on the same head succeeded) is a concrete, falsifiable starting point, and the run timelines are preserved.

Size/model suggestion: S–M, opus for the diagnosis (concurrency semantics are easy to get subtly wrong); the eventual YAML change is likely small. Note this is a gate-infrastructure edit, not a gate weakening — no threshold or required check may be removed under cover of this fix.

本评论来自分诊座位 Routine。

---

Generated by Claude Code

[qq9340100]

Claim: PM loop round 4 (accelerated batch per maintainer instruction)
Session: session_01Jqe56GnYFddggeAyfkZFVz
Branch: claude/issue-8409-gate-workflow-cancelled
Worktree: objectstack-issue-8409
Domain: domain:devx
File surface: .github/workflows/lint.yml + .github/workflows/ci.yml concurrency: blocks only (diagnosis may READ run records via API; no other file edited) (stop on breach; explain in the report)
Container & model: S–M, mode:subagent, model: opus (concurrency semantics diagnosis)
Serial constraints cleared: no in-flight claim declares either workflow file (#8331 is a held finding on lint.yml, not in flight). Claim-time reading of both blocks: group: <wf>-${{ github.workflow }}-${{ github.event.pull_request.number || github.ref }} with cancel-in-progress: true — the merge_group-event fallback to github.ref is the card's own prime suspect. ⚠️ Any lint.yml edit pulls in the seven workflow gate families; ⛔ no threshold or required check may be removed under cover of this fix (triage note, restated).

---

Generated by Claude Code

[qq9340100]

{
 "issue": 8409,
 "status": "done",
 "branch": "claude/issue-8409-gate-workflow-cancelled",
 "pr": null,
 "premise_still_valid": false,
 "summary": "PREMISE FALSIFIED — no workflow defect exists; no PR, and the concurrency blocks must NOT be changed. Both incidents had a newer push on the SAME PR branch, and cancel-in-progress behaved exactly as designed. Incident 1 (PR #8335): runs on e5d3457 created 06:10:14Z; commit 943f7b7 pushed to the same branch at 06:13:29Z; the e5d3457 lint run was cancelled at 06:13:44Z (15s later) and CI at 06:14:00Z (31s later); 943f7b7's own runs 31673053752/31673053770 both green; PR merged 09:25:25Z on 943f7b7. Incident 2 (PR #8396): runs on 9800bae created 11:02:22Z; commit 542fba8 pushed at 11:04:10Z; the 9800bae lint/CI runs were cancelled at 11:04:17-18Z (7-8s later); 542fba8's runs 31693878371 (lint, success 11:20:06Z) and 31693878372 (CI, success 11:17:59Z) both green; PR merged 11:52:42Z on 542fba8. The PM's prime suspect (merge_group sharing a group with pull_request) is falsified three ways: merge_group runs carry head_branch gh-readonly-queue/main/pr-NNNN-SHA, so github.ref is refs/heads/gh-readonly-queue/... — never numerically equal to a PR number; the queue entries live at that time were for PRs 8377/8383/8384/8369/8380, none of them 8335 or 8396; and merge_group and pull_request runs coexisted throughout the window concluding independently (success/failure), with zero cross-cancellation. The card's supporting observation — 'only the two heavyweight gate carriers were cancelled while all siblings on the same head succeeded' — is fully explained by DURATION, not workflow identity: on both heads every sibling finished in 9-50s (well inside the 195s and 108s windows before the newer push), while the carriers take 10-15 min. Control case proving it: branch claude/issue-8351, head 475c6d5, one push (3a242b7 at 10:55:39Z) — CI 31693210988 had finished at 10:55:33Z and concluded success, lint 31693211052 was still running and was cancelled at 10:55:56Z. Same head, same push, same event; the only difference is who had finished. Any change here would remove the same-PR supersession the dispatch explicitly requires preserving — i.e. exactly the gate weakening the 裁决 forbids.",
 "tests": "No files changed, so no build/test/gate run applies. Verification was read-only against the preserved run records via the REST API. Evidence chain: (1) GET runs/31672859420/attempts/1 -> conclusion=cancelled, created=2026-08-13T06:10:14Z, updated=2026-08-13T06:13:44Z; runs/31672859375/attempts/1 -> cancelled, updated=06:14:00Z; (2) GET runs/31693746175/attempts/1 -> cancelled, created=11:02:22Z, updated=11:04:18Z, and its ESLint job 94426670979 shows step 9 'Slot-lookup ratchet' conclusion=cancelled at 11:04:15Z with steps 1-8 all success — killed mid-flight, not a job failure; (3) workflow-run listings for lint.yml and ci.yml over created=2026-08-13T10:45..11:15 and the incident-1 branch over 06:00..06:45 place the superseding runs (31673053752/70 on 943f7b7 at 06:13:29Z; 31693878371/2 on 542fba8 at 11:04:10Z) seconds BEFORE each cancellation; (4) GET pulls/8335 and pulls/8396 confirm head.sha=943f7b7 and 542fba8 with the superseded SHAs listed as earlier commits on the same PR — same PR, not a different branch; (5) GET actions/runs?head_sha=... for both stale heads lists every sibling workflow with its updated_at, giving the 9-50s completion times; (6) merge_group ref shape read from run 31693242227 (head_branch=gh-readonly-queue/main/pr-8383-ebb14ece...). Provenance check: git log on both workflow files shows the concurrency blocks last changed in b7a86ea5f (2026-08-13 00:40:30Z, PR #8253), i.e. before both incidents — the code analyzed is the code that ran. The seven workflow gate families and check:nul-bytes are moot with an empty diff; I did not run them and am not reporting readings for them rather than fabricating any. dispatch-gates.mjs was likewise not re-derived: there are no changed paths to derive from.",
 "open_questions": [],
 "out_of_scope_findings": [
 "filed as #8434: PM gate-reading does not pin the run to the PR's CURRENT head — measured cost of exactly this misreading: the #8396 rerun of stale head 9800bae (attempt 2, 11:26:58Z) FAILED on 'Check generated reference docs are in sync with the spec', the very defect that current head 542fba8 ('docs(spec): regenerate references for the new ledger row') had already fixed, hanging a false red on a PR that was green; the #8335 rerun burned ~40 min of runner time on a dead commit. Lands in .claude/skills/pm-dispatch (review-checklist.md requires the carriers' conclusion be success but never says on which commit). Filed unassigned, unlabeled for triage."
 ]
}

Note on the dispatch's landing clause: it anticipated a normal-path draft PR. There is nothing to land — the workflows are correct as written, and the only actionable defect is procedural and outside this card's declared file surface, so it went to #8434 rather than into an out-of-scope edit here. Recommend closing #8409 as not-planned with a pointer to #8434.

---

Generated by Claude Code

---

Generated by Claude Code

[qq9340100]

ACCEPT (premise falsified) + close — no PR, and that is the correct deliverable (round 4, domain:devx seat)

premise_still_valid: false with pr: null — reviewed against the evidence chain, not the report's self-description. The card's central claim ("cancelled on a PR head with no newer push") is measured false for BOTH incidents:

incident	stale head runs created	newer push on the SAME PR	cancellation
PR #8335	06:10:14Z (e5d3457)	943f7b7 at 06:13:29Z	06:13:44Z / 06:14:00Z — 15s/31s after the push
PR #8396	11:02:22Z (9800bae)	542fba8 at 11:04:10Z	11:04:17-18Z — 7-8s after the push

Both superseding heads ran green and both PRs merged on them. cancel-in-progress did exactly what it exists for.

The card's supporting observation is explained, not just dismissed: siblings on the same head finished in 9–50s — inside the 195s/108s windows before the newer push — while the two heavyweight carriers take 10–15 min. The control case seals it: same branch, same push, same event — the CI run that had already finished concluded success; the lint run still in flight was cancelled. Duration, not workflow identity.

The prime suspect (merge_group/pull_request group collision) is falsified three independent ways: merge_group refs are refs/heads/gh-readonly-queue/main/pr-NNNN-SHA (never colliding with a PR-number key); the queue entries live in the window were PRs 8377/8383/8384/8369/8380 (neither incident PR); and merge_group + pull_request runs coexisted throughout with zero cross-cancellation.

Why closing is right and a "fix" would have been harm: any change to these concurrency: blocks aimed at this symptom would remove same-PR supersession — the one behavior the blocks exist to provide — i.e. exactly the gate-infrastructure weakening the dispatch forbade. The dev also correctly reported the gates as NOT RUN on an empty diff instead of fabricating readings.

Closing as not planned (the observed behavior is by design; the operational cost the card measured is real but its remedy is a process fix, carried by the out-of-scope finding below). Maintainer veto-reopen applies as always.

The real deliverable this produced

#8434 (filed unassigned, for triage → skills seat): PM gate-reading does not pin the run to the PR's current head — and the cost is measured on this card's own incidents: the #8396 manual rerun re-ran a STALE head and hung a false red on a PR whose current head had already fixed the failure; the #8335 rerun burned ~40 min of runner time on a dead commit. This seat adopts the discipline immediately (check-run readings verified against the PR's current head SHA before any flip), ahead of the skills-side fix.

---

Generated by Claude Code