fix: serialize bump-and-open-pr per package to close a burst-supersede race - #5
Merged
Merged
Conversation
…e race Several releases of the same sibling package publishing within seconds of each other each fire their own repository_dispatch event, and GitHub runs one bump-and-open-pr job per event fully in parallel. The close-then-create step reads a live snapshot of currently-open PRs for the package -- under real concurrency every run in the burst takes that snapshot before any sibling run has created its own PR, so none of them see anything to close and all survive side by side. Confirmed directly against novus-power/hive: a burst of pdf-codec releases fired nine repository_dispatch-triggered runs within 8 seconds of each other, and all nine PRs survived instead of only the newest. Add a job-level concurrency group keyed by package name, non-cancelling so an in-flight push/PR-create is never killed mid-operation. GitHub's own queueing semantics collapse a same-package burst to at most two real executions rather than fully serializing it, which is what we want here anyway -- every run in between would otherwise open and immediately close its own now-superseded PR for nothing.
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
🎉 This PR is included in version 1.0.3 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
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.
Follows up on #2. That fix correctly closes an older sibling-update PR when a new release dispatches after it, but never covered several releases of the same package publishing within seconds of each other: each publish fires its own repository_dispatch event, and GitHub runs one bump-and-open-pr job per event fully in parallel with no visibility into siblings' in-flight work. The close-then-create step's "list currently-open PRs for this package" snapshot then predates every sibling run's own PR creation, so none of them close anything and all survive side by side.
Confirmed directly against novus-power/hive: a burst of pdf-codec releases fired nine repository_dispatch-triggered runs within 8 seconds of each other, and all nine PRs survived instead of only the newest.
Adds a job-level
concurrencygroup onbump-and-open-pr, keyed by package name (concurrency groups are already scoped per-repository by GitHub, so this never collides across caller repos), non-cancelling so an in-flight push or PR-create is never killed mid-operation. GitHub's own queueing semantics collapse a same-package burst to at most two real executions rather than fully serializing every release in it, which is the outcome we actually want -- every run in between would otherwise open, then immediately close, its own now-superseded PR for nothing.Test plan
actionlint -ignore 'property "automerge_app_private_key" is not defined'-- cleannpx prettier --check .-- clean