Filed unassigned by the domain:devx os-dev seat while landing #9711. Recording, not claiming — it came out of that card's H4 sweep for other consumers of a closing keyword parsed out of user-authored text, and it is a different defect class (a target that is never recognised, not a target of the wrong kind), so it was left out of that PR. Dedup-searched over the 238 open issues in this repo (Fixes:, "optional colon", duplicate-fix-guard, the Chinese phrasing): no card covers it.
The divergence
Two workflows parse the same grammar out of PR bodies and spell it differently.
.github/workflows/duplicate-fix-guard.yml accepts an optional colon, and says why:
// GitHub's own closing-keyword set. The optional colon is part of// GitHub's accepted syntax (`Fixes: #123`).`\\b(?:${KEYWORDS}):?\\s+(?:([\\w.-]+)\\/([\\w.-]+))?#(\\d+)\\b`.github/workflows/cross-repo-issue-closer.yml does not:
`\\b(?:${KEYWORDS})\\s+([\\w.-]+)\\/([\\w.-]+)#(\\d+)\\b`Run against the same three bodies (node, both regexes, today):
| body | cross-repo-issue-closer | duplicate-fix-guard |
|---|
Fixes objectstack-ai/objectui#456 | matches | matches |
Fixes: objectstack-ai/objectui#456 | no match | matches |
Closes: #4500 | no match (bare form, correctly ignored) | matches |
Why it matters
A merged PR body written Fixes: objectstack-ai/objectui#456 takes the closer's exit path 1 — No cross-repository closing keywords in this PR body. — which is the same quiet, green line a body with no cross-repo reference at all produces. The foreign issue stays open, no notice is posted on the PR, and nothing distinguishes the run from the ~2300 runs that genuinely had nothing to do. That is the silent-path shape this file's whole card family (#9373 · #9424 · #9575 · #9595 · #9643 · #9711) has been closing one exit at a time.
At most one of the two spellings can match GitHub's real parser, and whichever it is, the two files should not disagree: one of them decides whether an issue in another repository gets closed, and the other decides whether a PR goes red for claiming an issue someone else claimed.
Severity
Low and measured, same as its siblings: across the 1176 most recently merged PRs there are zero qualified cross-repo closing keywords of any spelling, so this path has never had a target. It is cheap to get right.
What the fix needs
Decide the authority first — GitHub's documented syntax, checked against a real reference in this repo, rather than either comment's assertion — then make the two regexes agree, and pin the answer with a scenario in scripts/check-cross-repo-closer-outcome.mjs (its P1 scenario already asserts which spellings qualify and which must not, so the colon case belongs there) plus a matching mutation in --self-test. If the colon is genuinely not GitHub syntax, the edit is in duplicate-fix-guard.yml instead, and the same reasoning applies in reverse.
Ref: #9711 · #9643 · #9595 · #9575
Filed unassigned by the
domain:devxos-dev seat while landing #9711. Recording, not claiming — it came out of that card's H4 sweep for other consumers of a closing keyword parsed out of user-authored text, and it is a different defect class (a target that is never recognised, not a target of the wrong kind), so it was left out of that PR. Dedup-searched over the 238 open issues in this repo (Fixes:, "optional colon",duplicate-fix-guard, the Chinese phrasing): no card covers it.The divergence
Two workflows parse the same grammar out of PR bodies and spell it differently.
.github/workflows/duplicate-fix-guard.ymlaccepts an optional colon, and says why:.github/workflows/cross-repo-issue-closer.ymldoes not:`\\b(?:${KEYWORDS})\\s+([\\w.-]+)\\/([\\w.-]+)#(\\d+)\\b`Run against the same three bodies (node, both regexes, today):
Fixes objectstack-ai/objectui#456Fixes: objectstack-ai/objectui#456Closes: #4500Why it matters
A merged PR body written
Fixes: objectstack-ai/objectui#456takes the closer's exit path 1 —No cross-repository closing keywords in this PR body.— which is the same quiet, green line a body with no cross-repo reference at all produces. The foreign issue stays open, no notice is posted on the PR, and nothing distinguishes the run from the ~2300 runs that genuinely had nothing to do. That is the silent-path shape this file's whole card family (#9373 · #9424 · #9575 · #9595 · #9643 · #9711) has been closing one exit at a time.At most one of the two spellings can match GitHub's real parser, and whichever it is, the two files should not disagree: one of them decides whether an issue in another repository gets closed, and the other decides whether a PR goes red for claiming an issue someone else claimed.
Severity
Low and measured, same as its siblings: across the 1176 most recently merged PRs there are zero qualified cross-repo closing keywords of any spelling, so this path has never had a target. It is cheap to get right.
What the fix needs
Decide the authority first — GitHub's documented syntax, checked against a real reference in this repo, rather than either comment's assertion — then make the two regexes agree, and pin the answer with a scenario in
scripts/check-cross-repo-closer-outcome.mjs(itsP1scenario already asserts which spellings qualify and which must not, so the colon case belongs there) plus a matching mutation in--self-test. If the colon is genuinely not GitHub syntax, the edit is induplicate-fix-guard.ymlinstead, and the same reasoning applies in reverse.Ref: #9711 · #9643 · #9595 · #9575