Filed unassigned by the domain:devx os-dev seat while landing #9575 / PR #9594. Recording, not claiming. Dedup-searched (221 open issues, workflow name + phrasing): the only other card naming this file is #9575 itself, whose scope is the other call site.
The finding
.github/workflows/cross-repo-issue-closer.yml's per-target loop is guarded, and its guard is the right shape for the isolation it buys — one unreachable target must not take the rest down. But the isolation and the job's OUTCOME are separable, and today only the first exists:
}catch(error){// One unreachable target must not swallow the rest, and a// failure here must not read as success.core.warning(`Could not close ${key}: ${error.message}`);}The comment states the requirement — "a failure here must not read as success" — and the code does not meet it. core.warning leaves the job green. So when the close of a foreign issue is refused, the issue stays open, the PR carries no notice, and the job's conclusion is identical to the ~2268 runs where there was nothing to do at all. That is the same silence #9373 / #9424 / #9575 are about, one layer in.
Why this half is the LIVE one
#9575's notice path only runs while CROSS_REPO_ISSUE_TOKEN is missing, and sampled job logs show it configured on 2026-08-04, 08-08, 08-12, 08-16 and 08-18 — so that branch is latent. This loop is the branch that actually runs whenever a merged PR carries a qualified cross-repo closing keyword. It has not fired recently (the 489 most recent merged PR bodies contain zero such keywords), but when it does fire it fires on exactly the occasion the workflow exists for.
The shape a fix would take, if triage wants one
Not a mechanical edit, which is why this is a card and not a rider on PR #9594:
PR #9594 deliberately left this loop untouched: its dispatch scoped it to the unguarded notice, and the step-level retries: it adds only changes how many times a target is asked, never whether a spent failure is reported.
Ref: #9373 · PR #9423 · #9424 · PR #9574 · #9575 · PR #9594
Generated by Claude Code
Generated by Claude Code
Filed unassigned by the
domain:devxos-dev seat while landing #9575 / PR #9594. Recording, not claiming. Dedup-searched (221 open issues, workflow name + phrasing): the only other card naming this file is #9575 itself, whose scope is the other call site.The finding
.github/workflows/cross-repo-issue-closer.yml's per-target loop is guarded, and its guard is the right shape for the isolation it buys — one unreachable target must not take the rest down. But the isolation and the job's OUTCOME are separable, and today only the first exists:The comment states the requirement — "a failure here must not read as success" — and the code does not meet it.
core.warningleaves the job green. So when the close of a foreign issue is refused, the issue stays open, the PR carries no notice, and the job's conclusion is identical to the ~2268 runs where there was nothing to do at all. That is the same silence #9373 / #9424 / #9575 are about, one layer in.Why this half is the LIVE one
#9575's notice path only runs while
CROSS_REPO_ISSUE_TOKENis missing, and sampled job logs show it configured on 2026-08-04, 08-08, 08-12, 08-16 and 08-18 — so that branch is latent. This loop is the branch that actually runs whenever a merged PR carries a qualified cross-repo closing keyword. It has not fired recently (the 489 most recent merged PR bodies contain zero such keywords), but when it does fire it fires on exactly the occasion the workflow exists for.The shape a fix would take, if triage wants one
Not a mechanical edit, which is why this is a card and not a rider on PR #9594:
catchexactly as it is — the loop must still run to the end;core.setFailednaming them, the waymerge-queue-triage.ymldoes since merge-queue-triage.yml has the same untolerated comment-post as #9373 — and here the lost comment IS the flake evidence #9424;pull_request_target: [closed]so it gates nothing already merged, noworkflow_run:listener), so it is likely to land the same way — but it should be re-derived, not inherited.PR #9594 deliberately left this loop untouched: its dispatch scoped it to the unguarded notice, and the step-level
retries:it adds only changes how many times a target is asked, never whether a spent failure is reported.Ref: #9373 · PR #9423 · #9424 · PR #9574 · #9575 · PR #9594
Generated by Claude Code
Generated by Claude Code