Recover the release when mvn deploy fails after the Central upload - #16
Merged
Conversation
The release job for v0.4.2 (run 31701259508) published to Maven Central but then crashed: the central-publishing plugin's wait-until-published poll hit a transient 502 and failed the build after the bundle had already uploaded (deployments publish server-side from that point on). That aborted release.py before the git bookkeeping, stranding a published version with no tag, changelog entry, or GitHub release — and the next release attempt would collide with the already-published version. On a nonzero mvn exit, release.py now checks the Central Publisher API for whether the new version is live before giving up: polling for up to 10 minutes when the upload succeeded (detected from the plugin's output), or a single check otherwise. If the version is published, the release continues with the commit/tag/GitHub release. The single check also makes a failed release job safely re-runnable: the re-run's deploy fails on the duplicate version, the check sees it live, and the bookkeeping completes. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Merged
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.
Details
## ProblemThe release job for v0.4.2 (run 31701259508) successfully uploaded and published to Maven Central, but the central-publishing plugin's wait-until-published poll hit a transient 502 from Sonatype and failed the build:
Once the bundle is uploaded, the deployment validates and publishes server-side regardless of how the mvn process exits. So the failure aborted
release.pyafter the version was irrevocably going out but before any git bookkeeping: 0.4.2 went live on Central with no version-bump commit, no changelog entry, nov0.4.2tag, and no GitHub release — and withRELEASE.mdstill on main, the next push would have attempted to release 0.4.2 again and collided with the published version.Fix
release.pyno longer treats a nonzeromvn deployexit as unconditionally fatal. It now:Uploaded bundle successfullymarker;/api/v1/publisher/published, using the existingCENTRAL_TOKEN_*credentials) for up to 10 minutes, and continues with the commit/tag/GitHub release once the version is live;If the version never shows up as published, the original failure is re-raised and the job fails exactly as before.
The recovery paths are exercised by stubbing
run_deploy/is_published: deploy-fails-but-published continues, deploy-fails-unpublished re-raises immediately, uploaded-but-never-publishes raises after the deadline, missing credentials re-raise without touching the API, and the success path is unchanged.(The v0.4.2 incident itself was repaired by hand: bookkeeping commit, tag, and GitHub release replayed on main.)
🤖 Generated with Claude Code