xtask: re-read manifests in execute-plan apply loop - #6200
Merged
Conversation
The preflight loop parsed every package manifest up front and the apply loop reused those in-memory copies. Bumping a package rewrites the on-disk manifests of its workspace dependents, so a package bumped after its dependencies had those rewrites on disk - but its own bump step then saved its stale pre-bump snapshot, silently reverting them. esp-hal is bumped last and depends on nearly every other released crate, so it lost all of its intra-workspace dependency bumps (e.g. the esp-config build-dependency stayed at the old requirement), which broke the release build. Re-read each manifest from disk immediately before bumping so dependency rewrites from earlier steps are preserved. Regression from esp-rs#5644, which moved the manifest load into an up-front preflight loop and reused the parsed copies. Co-authored-by: Cursor <cursoragent@cursor.com>
find_existing_pr can miss a just-created PR because GitHub's PR listing lags for a moment after execute-plan force-pushes the release branch. On a re-run the lookup returned nothing, so `gh pr create` ran a second time and re-applied every release label and re-requested code-owner reviews, which showed up as duplicated PR timeline entries. Recover from `gh pr create`'s "a pull request ... already exists" error by parsing the existing PR number and editing that PR (title and body only) instead of bailing or opening a duplicate. Labels are still applied exactly once, on first creation, so a maintainer removing one to skip its optional CI check is respected. Co-authored-by: Cursor <cursoragent@cursor.com>
MabezDev
added
skip-changelog
bugadani
approved these changes
Aug 25, 2026
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
2 participants
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.
The preflight loop parsed every package manifest up front and the apply
loop reused those in-memory copies. Bumping a package rewrites the
on-disk manifests of its workspace dependents, so a package bumped after
its dependencies had those rewrites on disk - but its own bump step then
saved its stale pre-bump snapshot, silently reverting them.
esp-hal is bumped last and depends on nearly every other released crate,
so it lost all of its intra-workspace dependency bumps (e.g. the
esp-config build-dependency stayed at the old requirement), which broke
the release build. Re-read each manifest from disk immediately before
bumping so dependency rewrites from earlier steps are preserved.
Regression from #5644, which moved the manifest load into an up-front
preflight loop and reused the parsed copies.
I already used this commit in the latest rc release.