Repository navigation
Changeset gate accepts 0000- and wrong-PR changelog fragment names #8978
Description
The gap
The changeset gate in lint accepts any fragment matching:
^changelog\.d/[0-9]+-[^/]+\.md$
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 PR
changelog.d/README.md says 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 by scripts/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:
| PR | shipped as | should have been |
|---|---|---|
| #8944 | 0000-inline-array-pop-tier.md |
8944- |
| #8947 | 0000-inline-method-shape-probe.md |
8947- |
| #8291 | 0000-node-version-26.5.1.md |
8291- |
| #8977 | 8976-write-stub-two-way.md |
8977- |
The first three sat on main until #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:
- Backfills/cleanups. chore(changelog): give the three 0000 fragments their PR numbers #8973 renamed three fragments to
8944-,8947-and8291-— none of them its own number. A strict rule blocks exactly the PR that repairs the problem. - Stacked PRs where a fragment legitimately names the parent change.
So the check needs to be "the number is this PR's, or an existing PR number", or to warn rather than fail. The 0000 case 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.
Activity
proggeramlug commentedon Aug 28, 2026
More evidence, from a single batch of three PRs merged tonight — all three were wrong, in three different ways:
8958-dynamic-function-refusal-unwind.mdcrates/, noskip-changeloglabel — the gate would have rejected it8981-feedback-gate-and-shape-field.mdNote 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.
fix(ci): reject the 0000- changelog placeholder and warn on a wrong n…
test(codegen): pin the source-small preinline admission, and fix the …
perf(codegen): admit source-small guarded specializations to the pre-…
docs: renumber the changeset fragment 9016 -> 9021
perf(runtime,codegen): computed reads take the key by value (computed…
docs: renumber the default-on fragment 9037 -> 9038
feat(runtime): tombstone object deletes default-on (populated delete …