ci(npm): tolerate already-published race in npm publish (closes #70)#72
Merged
Conversation
Closes #70. The workflow's two triggers (release.yml explicit dispatch + workflow_run on Release completion) fire back-to-back per release. The static concurrency group already serializes the runs, but the second run's pre-publish `npm view` guard races npm's read-after-write propagation: a version published seconds earlier may not be visible yet, so the guard passes and the publish dies with E403 "cannot publish over the previously published versions" — a spurious red X on an otherwise successful release (observed on v0.0.25). Treat that 403 as the success it is: capture the publish log, match the already-published error, and exit 0. As a last resort, re-poll `npm view` (3 x 5s) before declaring real failure. Genuine publish failures (auth, network, validation) still fail the job. Control flow verified with a mocked npm for all three paths (publish-ok, 403-race, hard-failure). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
There was a problem hiding this comment.
Pull request overview
This PR updates the npm publish GitHub Actions workflow to avoid spurious failures when two serialized publish runs still race npm registry read-after-write propagation (the version is published but npm view can lag briefly), closing #70.
Changes:
- Capture
npm publishoutput and treat the specific “already published” E403 failure as a successful end state. - Add a short (3×5s)
npm viewre-poll backstop before failing on other publish errors. - Refactor publish flags into a
publish_argsarray to avoid duplication.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Comment on lines
+279
to
284
| publish_log="$(mktemp)" | ||
| if (cd npm && npm publish "${publish_args[@]}") 2>&1 | tee "$publish_log"; then | ||
| echo "${package_name}@${VERSION} published." | ||
| elif grep -q "cannot publish over the previously published versions" "$publish_log"; then | ||
| echo "${package_name}@${VERSION} was already published by a concurrent run; treating as success." | ||
| else |
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.
Summary
Fixes the spurious red X on releases (#70, observed on v0.0.25).
Corrected diagnosis: the concurrency group proposed as option 2 in the issue already exists and works — the runs do serialize. The actual gap is that the second run's pre-publish
npm viewguard races npm's read-after-write propagation: the version published seconds earlier isn't visible yet, so the guard passes andnpm publishexits with E403 "cannot publish over the previously published versions".Fix (issue option 1): capture the publish output; if it fails with the already-published 403, treat it as success (the version is on the registry — that's the goal state). A 3×5s
npm viewre-poll backstops any other transient visibility lag. Genuine failures (auth, network, validation) still fail the job.Test plan
npmfor all three paths: normal publish → success; 403 race → success with explanatory log line; hard failure (E401) → job fails.Closes #70.
🤖 Generated with Claude Code