Retry the npm tarball fetch long enough to survive real propagation lag - #19
Merged
Merged
Conversation
…ion lag Confirmed directly against the v2.3.0 release: npm's package metadata and its tarball blob storage are separate backing stores, and the metadata went live and stayed resolvable (npm view, a bare npm install) several minutes before the tarball itself stopped 404ing at its own documented URL. The registry's status page reported no incident, and an unrelated, long-published package's tarball resolved instantly throughout, so this was never registry downtime, just the ordinary gap between the two stores landing further apart than usual. install.sh's macOS x64 fallback (which needs npm because that architecture's SEA binary segfaults on every invocation) had no retry at all around npm install — a real user running this script inside that window got a hard, unrecoverable failure for a release that was, from every other angle, already fully published. It now retries for up to ten minutes, matching what was actually observed rather than a guess. Two CI-only checks hit the identical gap with budgets an order of magnitude too small to survive it: verify-npm's own retry loop (10 attempts, ~100s) and update-tap's curl fetch of the npm tarball for the Homebrew formula's checksum (12 attempts, ~96s). Both widened to the same ten-minute budget.
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 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.
The v2.3.0 release CI run just failed six jobs (
Verify npm installon all four platforms,Update Homebrew tap,Verify install.sh (macOS x64)) with the identical symptom:npm view claude-use versionand a barenpm install claude-useboth correctly resolved 2.3.0, but the tarball athttps://registry.npmjs.org/claude-use/-/claude-use-2.3.0.tgzkept 404ing.Confirmed this wasn't registry downtime before touching anything: npm's own status page reported all systems operational, and both
lodash's tarball and claude-use's own previous (2.2.0) tarball resolved instantly the whole time. Polled the exact URL directly — it took just over 7 minutes afternpm publishreturned success before the tarball actually became downloadable, well past every retry budget in this repo that assumes it (all sized around 90–100 seconds). Once it came back, re-running the failed jobs went green with no other change, confirming this was propagation lag, not a real defect in the published package.install.sh's macOS x64 fallback (needed because that architecture's SEA binary segfaults on every invocation) had no retry around itsnpm installcall at all — a real user running the installer in that window would hit a hard failure for a release that was, from every other angle, already fully published. Added a retry loop there, and widened the two CI-only budgets (verify-npm's own loop,update-tap's curl fetch for the Homebrew formula's checksum) to the same ~10-minute budget, matching what was actually observed.Unrelated to #18 — that PR's own release is what surfaced this, but the fix here is a standing CI/install robustness gap, not something #18's own diff caused.