Repository navigation
Changeset gate accepts 0000- and wrong-PR changelog fragment names #8978
Description
Activity
More evidence, from a single batch of three PRs merged tonight — all three were wrong, in three different ways:
PR shipped as problem #8981 8958-dynamic-function-refusal-unwind.mdnamed for the issue it fixes, not the PR #8982 (none) touches crates/, noskip-changeloglabel — the gate would have rejected it#8983 8981-feedback-gate-and-shape-field.mdcarries #8981's number, a different PR in the same batch Note the last one: left alone, #8983's fragment would have collided with #8981's own fragment at release time, and both landed within minutes of each other.
Running total for 2026-08-28 is eight fragment-naming fixes across the day (three
0000-placeholders, four wrong-PR numbers, one missing). Only the missing one was catchable by the current gate.The asymmetry is the point: the gate reliably catches an absent fragment and never catches a misattributed one, and misattribution is the failure that survives to the release notes.
- added a commit that references this issue
on Aug 29, 2026 - added 6 commits that reference this issue
on Aug 29, 2026
The gap
The changeset gate in
lintaccepts any fragment matching:That requires some digits, not this PR's number. So both of these pass:
changelog.d/0000-<slug>.md— the placeholder, when an author has not filled in the number yetchangelog.d/<other-PR>-<slug>.md— a number belonging to a different PRchangelog.d/README.mdsays filenames are PR-keyed precisely so in-flight PRs cannot collide, and the failure is silent: fragments are only folded into release notes at tag time byscripts/cut_release_notes.sh, so a wrong number is invisible until a release is cut and then attributes the change to the wrong PR.Evidence it happens
Four in one day (2026-08-28), all caught by eye during review rather than by any gate:
0000-inline-array-pop-tier.md8944-0000-inline-method-shape-probe.md8947-0000-node-version-26.5.1.md8291-8976-write-stub-two-way.md8977-The first three sat on
mainuntil #8973 renamed them; the fourth misattributed a write-stub change to #8976, an unrelated Array-subclass loop-guard fix that had merged an hour earlier.Why the obvious fix is wrong
"The fragment must start with this PR's number" would be a false positive on legitimate cases:
8944-,8947-and8291-— none of them its own number. A strict rule blocks exactly the PR that repairs the problem.So the check needs to be "the number is this PR's, or an existing PR number", or to warn rather than fail. The
0000case specifically is unambiguous though: no PR is ever number 0, so rejecting^changelog\.d/0+-is a safe tightening on its own and would have caught three of the four above.Suggested minimum
Reject
0000-(and any all-zero prefix) outright; treat a number that is neither this PR's nor an existing PR as a warning. That closes the common case without breaking cleanups.Found while auditing the PR queue; not fixed here because a naive tightening would have blocked #8973.