Uh oh!
There was an error while loading. Please reload this page.
(fix): accept generated notes on the draft release - #90
Merged
Conversation
createDraft requests generate_release_notes, so GitHub returns the body it was sent with the generated changelog appended. Both draft checks then compared that body for equality against what was sent, so the comparison could never hold and every release died after the tag and draft already existed — leaving exactly the half-finished state recovery has to unpick. Require the body to open with the automation markers instead. That is the property the safety check depends on, and RecoverySelector already reads the markers this way rather than demanding an exact body. Name the mismatching fields too: the message listed none of the six it compared, which is why a guaranteed failure took a release run to explain. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Greptile SummaryThis PR allows GitHub-generated release notes to follow the automation-owned draft body while retaining exact validation of release metadata and marker content.
Confidence Score: 5/5The PR appears safe to merge, with the intended suffix relaxation bounded by independent release metadata and marker validation. The expected automation body must still match exactly at the beginning of the draft, all release state fields remain checked, and final publication additionally validates marker uniqueness and merge correspondence. Important Files Changed
Reviews (1): Last reviewed commit: "(fix): accept generated notes on the dra..." | Re-trigger Greptile |
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 freeto 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.
Fixes run 32446810818, which tagged
2.0.1, drafted the release, then died onDraft release 374170913 is unsafe.The defect
GitHub::createDraftasks GitHub for generated notes:so the release GitHub returns has the automation's body plus the generated changelog appended. Both draft checks then compared that body for equality against what was sent:
That comparison can never hold while notes are generated, so the release step could not succeed on any run. It is not a flake — every dependency release would have died at exactly this point, after the tag and the draft already existed, leaving the half-finished state recovery then has to unpick.
The rejected draft is intact and correct —
tag_name: 2.0.1,target_commitish: 8a93696,draft: true, markers present. Only the equality check was wrong.Why a prefix check, not dropping the generated notes
Dropping
generate_release_noteswould also fix it, but the generated changelog is what previous releases shipped and is worth keeping. The property the safety check actually depends on is that the automation's markers —dependency-automation:v1,dependency-target:<sha>,dependency-pull:<n>— are present and unaltered at the head of the body.str_starts_withasserts exactly that, and everything else in the check (tag, target, pull, draft, prerelease) is unchanged.RecoverySelector::matchesalready reads the markers rather than demanding an exact body, so this makes the two paths consistent.Diagnosability
Draft release <id> is unsafenamed none of the six fields it compared, which is why a guaranteed failure needed the API response and the source side by side to explain. Both sites now list which fields mismatched.Verification
test_accepts_a_draft_with_generated_notes_appendedreproduces the production failure: a draft whose body is the automation body plus a## What's Changedblock. Confirmed it errors withis unsafeagainst the old equality check and passes with the fix.test_rejects_a_draft_whose_markers_were_rewrittenkeeps the safety property honest — a draft carrying a differentdependency-pullmarker is still rejected, with the new message naming the body.composer verify: Pint, PHPStan max, 154 tests / 1815 assertions, 91 parity contracts.Not verified
2.0.1.