Record the CHANGELOG entries for thirty-three changes across twenty-six merged pull requests - #3213
Merged
Merged
Conversation
…e merged pull requests Applies the `[Unreleased]` entries for the pull requests merged to `dev` from #3150 (the previous batch) through #3203. Lanes do not edit `CHANGELOG.md` -- every one of them appends to the same block, so a per-PR edit conflicts with whichever sibling merges first -- and the entry text rides each PR's own description instead. This is the periodic commit that applies it. `CHANGELOG.md` only, 56 insertions and no deletions: 31 entries prepended inside `## [Unreleased]` (6 under `### Added`, 2 under `### Changed`, 23 under `### Fixed`), newest merge first within each section, plus the 25 link-reference definitions they need appended at the foot of the file. Nothing already in the block was edited, reworded or reordered. Three of the 28 pull requests in the range earn no entry, each on measured precedent rather than judgement: #3150 is the previous batch pass itself, and no batch pass -- #2260, #2980, #3150 -- is cited anywhere in the file; #3130 and #3131 are routine Dependabot bumps, and none of the six merged Dependabot pull requests in the repository's history is cited either. Two pull requests carried no entry text anywhere, so theirs are written from their descriptions: #3176 (`pg_index_bloat`'s measured block rate) and #3184 (the PostgreSQL target's permissions section).
#3205 merged while this batch was assembled, so `origin/dev` was merged in rather than rebased and its entry lands on top. An entry omitted because it arrived mid-batch is how a backlog restarts, and the batch's purpose is to make `[Unreleased]` current at its own merged base. One entry under `### Changed`, newest merge first ahead of #3195's, plus its link-reference definition. #3205 has no other pull request in the range behind it.
|
Reviewed. This PR touches only Mechanical checks performed against the diff:
One thing worth a sanity check on your end (not blocking): No other issues found. |
…of the PR bodies The entry text does not only ride the PR description. #3150's own account of the previous batch says 11 of its 66 entries came from a lane's handoff file in `~/Documents/pm-issue-queue-inbox/inbox/` rather than the body, and three files there carry dedicated entry text inside this range: `3164-changelog-entry.md`, `3166-changelog-entry.md` and `3169-changelog-entry.md`. Searching only the bodies missed the first two. - **#3164** (PR #3176) is no longer written from the PR description. Its lane wrote a full entry, and that text is used verbatim: it carries the 1,036 blocks/s upper bound, the reason the decoupling #3153 deferred is unreachable, the declined command-deadline route, the census deliberately not restated at the new ceiling, and the mutation that caught nothing. `[#2997]` joins the definition block at its ascending position, which that text cites and the file did not define. - **#3166** (PR #3168, absorbed and superseded by #3178) had no entry at all. #3178 grouped it into its own citation with a one-line summary, but its lane wrote a separate entry for the census that took `HeaviestHourlyRefreshObservedCeilingSeconds` from 594 s to 896 s and inverted the watch-line ordering. It sits beside #3178's, on #3178's merge. - **#3191's entry** said "#3184 named four of the six". #3184 was squash-merged and the four-of-six state never reached `dev`; it was a commit inside that PR, corrected before merge. "shipped" in this file means merged, so the clause now says a commit in #3184, which is what the #3187 lane's own report establishes. `CHANGELOG.md` only, 60 insertions and no deletions against `origin/dev`: 33 entries (6 Added, 3 Changed, 24 Fixed) and 27 definitions. All 15 definition runs keep the ordering they had, 9 of 15 ascending before and after.
erikdarlingdata
changed the title
…scription #3184's entry now exists, staged by the lane that did the work, so the batch no longer invents one. Used verbatim, in `### Fixed` where its author targeted it and for the reason they gave: the section did not merely lack detail, it asserted "One role covers every collector", which is false in the direction that fails silently and which an operator would act on. Their text carries what a description-derived entry could not: the `pg_read_all_data` grant is PostgreSQL 14+ and the pre-14 fallback the section gave was `GRANT SELECT` on a schema, which is not valid PostgreSQL at all; the six collectors that need an extension, four of which additionally need `shared_preload_libraries` and a server restart; and why `pg_index_bloat` is unaffected by any grant. Both figures are live pre-change store reads rather than estimates. The citation is `[#3184]`, the pull request, because the change has no issue behind it, and its definition uses the `/pull/` form. `CHANGELOG.md` only, still 60 insertions and no deletions against `origin/dev`.
|
Reviewed. This is a docs-only batch ( Independent spot-checks against the PR description's claims, all consistent:
One thing worth a second look, though I think it's already justified in the description rather than a bug: No correctness, parity, or security issues found. |
erikdarlingdata
added a commit
that referenced
this pull request
Sep 9, 2026
…d pull requests, and strike an unsound claim from #3199's (#3232) * Record the CHANGELOG entries for seventeen changes across ten merged pull requests Applies the [Unreleased] entries for the pull requests merged to dev after #3213's batch pass, and strikes an unsound arithmetic claim from the #3199 entry that pass shipped. CHANGELOG.md only: 17 entries prepended inside [Unreleased] -- 5 under Added, 12 under Fixed -- plus the 15 link-reference definitions they need, and one edited line. Entry text comes from each pull request's own body where it carried one. * Cite #3224's own number on its entry, not the pull request it follows The Azure credential-recording entry led with [#3218], the pull request it is a follow-up to, which resolves to a different change. No issue exists behind #3224, so under the file's rule -- issue numbers where an issue exists, pull-request numbers where one does not -- its own number belongs in the citation position, with the follow-up relationship kept as prose. #3224 was the only one of the ten merged pull requests with no issue behind it whose number went uncited. The [#3218] definition is swapped for [#3224] rather than added, since nothing else cited it. * Absorb #3230, which merged mid-batch #3230 was open when this batch was cut and merged at 19:31:55Z while it was being verified, making it the newest merge in the range. origin/dev is merged in rather than rebased, so e459539 stays intact in the history. Its body carries no entry text and neither queue directory holds any, so the entry is written here from the description. No issue exists behind it, so it cites its own number, and its definition takes its ascending place between [#3226] and [#3231]. * Take #3230's entry from its own CHANGELOG block, not its measurement prose The entry was written from #3230's description before that description carried an entry-ready block, and the description's measurement section was taken at c9f04f3 -- before #3227's rebase moved Deadlock.cs LastTranStartedLocal onto FormatServerClock, which took it out of both the inventory and the string-literal subset. KnownTruncatedRanges has 30 entries; the retired entry said 31, and carried 13, 544, 510, 2,238 and 42,927 besides. The 544 and 510 predate the content-trim and cannot be recomputed from shipped code at all, and the file and declaration totals move with every commit. The lane's own block names only what shipped, so it replaces the entry wholesale rather than the numbers being patched. Its one quantity is cross-checked against the shipped array by the verification battery, so the entry cannot restate a count the code does not have.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Applies the collected
[Unreleased]entries for the pull requests merged todevfrom #3150 (the previous batch) through #3215. Lanes do not editCHANGELOG.md-- every one of them appends to the same[Unreleased]block, so a per-PR edit conflicts with whichever sibling merges first -- and the entry text rides each PR's own description instead. This is the periodic commit that applies it.What is in the diff
CHANGELOG.mdonly, 60 insertions and no deletions: 33 entries prepended inside## [Unreleased]-- 6 under### Added, 3 under### Changed, 24 under### Fixed-- plus the 27 link-reference definitions those entries need. 26 are appended as one ascending run at the foot of the file;[#2997]joins the previous batch's run at its own ascending position, so all 15 definition runs keep exactly the ordering they had (9 of 15 ascending, before and after). Entries are ordered newest-merge-first within each section, matching the file's existing order and asserted against each PR's ownmergedAt. Nothing already in the block was edited, reworded or reordered.The range, recomputed rather than inherited
30 pull requests merged to
devat or after #3150's own merge, counted three ways that fail differently:gh pr list --base devfiltered onmergedAt, the search API onis:merged base:dev merged:>=, andgit log --first-parentover the merge commits. All three return the same set, so the count does not rest ongh's default sort order (which is by creation date, and would silently drop an old PR merged late).The boundary is checked from the other side too, rather than assumed from the timestamp: #3150's own description states it covered "through #3147", and every issue behind the pull requests merged in the hour before it -- #3138, #3139, #3140, #3143, #3144, #3145 -- is already cited in the block. Nothing merged before the batch pass is uncovered by it.
The four that earn no entry, on measured precedent or their own say-so
CHANGELOG.md-only. No batch pass is cited anywhere in the file: CHANGELOG: backfill the five shipped changes that had no entry #2260, Record the CHANGELOG entries for twenty merged changes #2980 and Record the CHANGELOG entries for sixty-five merged changes #3150 all return zero for[#N].CHANGELOG.md, and Bump the nuget-patch-and-minor group with 7 updates #2336 and Bump the nuget-patch-and-minor group with 2 updates #2702 sat inside earlier batch ranges that did produce entries for their neighbours.Where the text came from
The remaining 26 pull requests contribute the 33 entries. The entry text does not only ride the PR description, and searching only the bodies was a partial search. #3150's own account of the previous batch says 11 of its 66 entries came from a lane's handoff file in the queue inbox rather than the body; three files there carry dedicated entry text inside this range, and two of them are entries the bodies do not have. #3164 (PR #3176) and #3166 (PR #3168, absorbed by #3178) are therefore taken from those files verbatim -- #3164's had been written from the PR description before the file was found, and #3166 had no entry at all. #3169's handoff file is byte-identical to the PR-body text, which is the control that says the extractor was reading the bodies correctly. Each entry is anchored on an exact substring of its own source, so the prose is the lane's rather than a re-summary: the assembler asserts the source's opening clause before reshaping it, and fails rather than guessing. Shaping is limited to what the block's existing entries require -- bolding the opening clause where a lane wrote a plain bullet, moving a trailing
(#NNNN)into the([#NNNN])position after the bold lead, unwrapping hard-wrapped source, and dropping a redundantFixed:/Added:prefix where the section heading already says it. Four PRs contributed more than one entry because they fixed more than one thing: #3163 (four), #3151, #3190 and #3202 (two each).No entry in this batch is written from a PR description. #3176 and #3184 were both in that category until their text was found -- #3176's in the queue inbox, #3184's staged in the outbox, a directory the first sweep did not search at all. Both are now the lane's own words. #3184's goes under
### Fixedfor the reason its author gave rather than one I chose: the section did not merely lack detail, it asserted "One role covers every collector", which is false in the direction that fails silently and which an operator would act on.Two further judgements are recorded rather than buried. #3177's and #3201's entry text each ends mid-sentence in the PR body; both are terminated with a period and nothing else is added. #3191's text cites a short commit SHA;
CHANGELOG.mdhas no precedent for one and it resolves to nothing for a reader, so the clause names a commit in #3184 instead. Not just "#3184": that PR was squash-merged and the four-of-six state never reacheddev-- it was corrected before merge -- and "shipped" in this file means merged, so naming the PR alone would have read as a stronger claim than the evidence supports. That distinction is the #3187 lane's own, from its handoff report.Citations
Citations are issue numbers where an issue exists and pull-request numbers where one does not, which is what the file already does. Enumerated rather than sampled, by intersecting every citation with the repository's full PR-number list (2,089 numbers) and confirming each new one against the API's own
pull_requestfield:/pull/NURL form is the current convention, and the file is not uniform about it. 318 PR-number definitions use/pull/Nand 136 use/issues/N-- so/issues/Nfor a PR is a third of the population rather than an anomaly. What separates them is age, not intent: the highest PR number still on the/issues/form is Part of #2874 #2928, and every PR-number definition above it uses/pull/. The new definitions use/pull/N.[#656]as/pull/656, and Agent job collector fails without msdb access #656 is an issue ("Agent job collector fails without msdb access"). Pre-existing, one line, outside this range, and left alone -- see the note at the end.Four entries here cite a PR because their change has no issue behind it: #3165, #3181, #3184 and #3168 (absorbed by #3178, and itself the source of a second entry under #3166). All 27 new numbers exist and resolve.
Four entries re-cite a number already defined in the file -- #2550, #3099, #2138 and #2673 -- because that is the issue each PR closes and the work is a later part of it. That is heavily precedented rather than a collision: 32 numbers already lead more than one entry inside
[Unreleased](#2874 leads fifteen), and no duplicate link definition is added for any of the four.Verification
CI takes the docs fast path on a change that ships no code, so a green
buildin seconds has run nothing and is not the evidence here. What was checked:git diff --numstat origin/devreports 60 insertions and 0 deletions, in the same positions Record the CHANGELOG entries for sixty-five merged changes #3150 used. A CRLF renormalize -- which this file has suffered twice, in Fix CHANGELOG.md: restore CRLF after an accidental LF renormalize (#2694 fallout) #2696 and Fix CHANGELOG.md: restore CRLF after a second accidental LF renormalize (#2695 fallout) #2697 -- would show as thousands of both. The file is read and written as bytes, and CRLF integrity is asserted before and after: 3,557 CRLF, zero bare LF, no BOM.[#NNNN]added has a definition, every definition added is cited by an added entry, no definition is duplicated, and none of the 27 already existed. The only definitions in the file cited by nothing are Charts should show visible flat line at zero instead of empty #85 and Deadlock pipeline latency: too many sequential hops before data reaches charts #86, which pre-date this change.git diffreports 32 added- **lines and 26 added definition lines, totalling the 58 in the diffstat; and independently extracting entries by their leading([#NNNN])citation -- a pattern that would undercount if any entry's citation were malformed -- also returns 32.## [headings and 81###headings before and after, identical as lists, and[Unreleased]'s three subsections stillAdded,Changed,Fixedin that order.04:28and00:28, the UTC-skew example in De-skew default_trace_events.event_time to UTC at every Darling read boundary (#3198) #3202's entry.A pre-existing inconsistency, reported rather than fixed
Two, both one line and both outside this range, deliberately not touched because a modification would put deletions into a diff whose zero-deletion property is the signal that the CRLF survived:
[#656]is defined as/pull/656and Agent job collector fails without msdb access #656 is an issue. The link redirects, so it renders.[#3083]is cited by nothing and defined by nothing, while Fixes #3083 #3086 -- the pull request that closed it -- is cited by the<see cref>entry the previous batch added. A handoff file for Nothing validates <see cref> targets: 22 dangling today, and the natural fix is the GenerateDocumentationFile decision parked in #3025 #3083 sits in the queue inbox. That is the previous batch's citation choice, not a gap this one created.Base
origin/devmoved twice while this was assembled. Both were merged in rather than rebased, socb208f6a4andb01e2a3c1are intact in the history, and #3205's entry lands in a commit of its own on top -- an entry omitted because it arrived mid-batch is how a backlog restarts, and the batch's purpose is to make[Unreleased]current at its own merged base. #3215 arrived on the second move and declines its own entry, quoted above. There is no pull request in the range whose entry this diff knowingly lacks.