fix(release): retry npm install on registry propagation lag in verify-published - #16
Merged
Merged
Conversation
…-published The Release workflow's post-publish verification checked the registry immediately after publish with no retry. That's a race, not a failure: npm registry propagation lags publish by seconds to low minutes. Run 29573402812 (2026-07-17T10:26:22Z, HEAD 5179bed) failed with "ETARGET: No matching version found for @workspacejson/spec@0.4.3" nine minutes before the same version was confirmed installable. The publish itself succeeded; only the immediate check was wrong. Retry the npm install step up to 6 times with linear backoff (5s/10s/.../30s) specifically on ETARGET/E404/"No matching version" errors — any other failure still fails fast, no retry. A gate that cries wolf on a known-benign race trains people to ignore red, which is the same failure mode that let a broken tarball sit on npm for 44 days (0.4.1/0.4.2 uninstallable, caught only by manual smoke test on 0.4.3). Verified against the real registry: @workspacejson/spec@0.4.3 installs on first attempt now, no retry needed, no regression to the happy path. Separate, pre-existing issue surfaced while testing this — NOT fixed here, flagging for a follow-up: `npx workspacejson-spec --help` exits 1 (prints "Usage: workspacejson-spec validate <file>" instead of handling --help), so this verification step can still fail after a clean install for a reason unrelated to registry timing. Needs a decision on intended --help behavior in @workspacejson/spec's CLI, not a guess from here.
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.
Why
Release run 29573402812 (HEAD
5179bed, 2026-07-17T10:26:22Z) shows Release: failure, but the publish itself succeeded —scripts/verify-published.mjschecked the registry immediately after publish and hitETARGET: No matching version found for @workspacejson/spec@0.4.3, a registry propagation race, not a real failure. The package was confirmed installable minutes later.A gate that cries wolf on a known-benign race trains people to ignore red — the same failure mode that let a broken tarball sit on npm for 44 days before the 0.4.1/0.4.2 CLI no-op bug was caught by manual smoke test. Flagged urgent since codex-mcp 0.1.5 publishes today and shouldn't add another false-red data point to the same dashboard.
What
Retry the
npm installstep up to 6 times with linear backoff (5s/10s/.../30s), scoped specifically toETARGET/E404/"No matching version" errors. Any other install failure still fails fast on the first attempt — this isn't a blanket retry, only a targeted one for the known propagation-lag shape.Verified against the live registry:
@workspacejson/spec@0.4.3installs on the first attempt, no retry triggered, no regression to the happy path.Separate issue found, not fixed here
While testing,
npx workspacejson-spec --helpitself exits 1 (printsUsage: workspacejson-spec validate <file>instead of handling--help). That means this verification step can still fail after a clean install, for a reason unrelated to registry timing. This PR doesn't touch it — needs a decision on intended--helpbehavior in@workspacejson/spec's CLI from someone who owns that package, not a guess under time pressure.