docs(changelog): state the raised token default the migration note announces - #576
Merged
Merged
Conversation
…nounces release-please generated two breaking-change bullets saying "The default is unchanged at 100000". ApplyDefaults ships 400000, and internal/docsguard's TestNoShippedDocClaimsTheTokenDefaultIsUnchanged fails the release PR on it — which is the guard doing its job, since an operator sizes their spend against the number the migration note gives them. Two mechanical causes, both on main and unrewritable. The squash body of 8d26929 carries TWO `BREAKING CHANGE:` footers, and release-please keeps a single breaking.text filled by the first body-level node — so the superseded footer won, and the correct paragraph (400000, the derived quarter, the compaction trigger, the measured overshoot) never reached the file. 0ef4507 inherited that footer from its stacked branch without a `!` in its subject, so the same wrong paragraph was emitted a second time under `eval:`. The `eval:` bullet is deleted rather than corrected: it is not a breaking change, and it only ever appeared because of the inherited footer. The `investigate:` bullet now states the raised default, what still bounds a single request, what happens to an explicitly-set value, that `0` applies the default while `-1` opts out, and the ~1.25x overshoot — and links the full migration. The prose is the one already pinned to the code in upgrade-uninstall.md, so the two cannot drift. `gitops:` was correct and is untouched. This file is regenerated whenever main moves, so this edit is applied last and must be re-applied if it regenerates again.
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
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.
Why
The 0.15.0 section of CHANGELOG.md carries two breaking-change bullets for
investigation.max_tokens_per_investigation, one underinvestigate:and a duplicate undereval:. Both say the default is unchanged at 400000, so the same number binds far earlier than it used to. That sentence was originally "unchanged at 100000"; a later fix patched the number sointernal/docsguardstops failing, but the claim itself is still false: the default was raised, from 100000 to 400000, precisely because the old value now binds far earlier. Bothdocs/configurationanddocs/operations/upgrade-uninstallalready say so.The duplicate came from a squash body that carried two
BREAKING CHANGE:footers; release-please picked the superseded one and emitted it twice (once under a spuriouseval:scope inherited from a stacked branch).What
eval:bullet: it was never a breaking change, only an inherited footer.investigate:bullet to the wording already pinned to the code inupgrade-uninstall.md: the raised default, the per-request quarter, what happens to an explicitly set value,0vs-1, the ~1.25x overshoot, and the migration link.gitops:is untouched.This is the parked commit from
fix/release-changelog-migration-note, cherry-picked onto current main (one context conflict resolved by keeping only the corrected line).Verified
go test ./internal/docsguard/...passes on this branch, and CI is green.