Give the post-publish read-back a window npm can meet - #11
Merged
Merged
Conversation
`validateAfterPublish` retried 6 times at 1.5s. Publishing 0.4.0 measured roughly two and a half minutes between a successful `npm publish` and the version becoming readable, so every one of the five packages published correctly and then failed its own verification. The publish job advanced exactly one package per run and took six runs to place a five-package set. The check was right to insist on reading the bytes back; it was wrong about how long npm takes to serve them. It now retries for five minutes and says how long it waited when it gives up. Nothing about what is verified changes — a version that never appears, or appears with foreign bytes, provenance, or tag, still raises `[PUBLISH_AMBIGUOUS]` and stops the set. The job's 15-minute timeout could not fit five packages at that rate either, so it moves to 45. A resumable publisher still leaves a partial publication to reconcile by hand if the job is killed mid-set. Two RELEASING.md claims that this release disproved: `npm trust list` reports `permissions: publish, stage publish` even when only `--allow-publish` is passed. npm grants both and the CLI offers no way to decline the second, so instructing the reader not to grant it described a choice they do not have. npm points `latest` at the first published version even when `--tag bootstrap` is the only tag requested, so the bootstrap step cannot leave `latest` absent. It is corrected when the real release publishes, and `[REGISTRY_TAG]` refuses to finish until every package's `latest` is the shared version.
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.
Why
Publishing 0.4.0 took six runs of the publish job to place five packages. Every package published correctly and then failed its own verification:
validateAfterPublishretried 6 times at 1.5s — about 9 seconds. Measured against npm during that release, a version took roughly 2.5 minutes to become readable after a successfulnpm publish. So the job advanced exactly one package per run.It failed closed throughout, which is the right direction — it never assumed a publish worked. The check was right to insist on reading the bytes back; it was wrong about how long npm takes to serve them.
What changed
validateAfterPublishnow retries for 5 minutes (60 × 5s) and reports how long it waited when it gives up. Nothing about what is verified changes — a version that never appears, or appears with foreign bytes, provenance, or tag, still raises[PUBLISH_AMBIGUOUS]and stops the set.publishjobtimeout-minutes15 → 45. Five packages at the observed rate do not fit in fifteen, and a job killed mid-set leaves a partial publication to reconcile by hand even though the publisher is resumable.release-publisher.mjsin the workflow's sealed-tool digests, since the publisher's bytes changed.Two RELEASING.md claims this release disproved
npm trust listreportspermissions: publish, stage publisheven when only--allow-publishis passed. npm grants both and the CLI offers no way to decline the second, so telling the reader not to grant it described a choice they do not have. All five packages show it, including the three configured for 0.3.latesttag. npm pointslatestat the first published version even when--tag bootstrapis the only tag requested, so the bootstrap step cannot leavelatestabsent. It self-corrects when the real release publishes, and[REGISTRY_TAG]refuses to finish until every package'slatestis the shared release version.Verification
check.mjs all,check.mjs workflow, and all five release self-tests pass. The workflow digest gate specifically confirms the re-pin.This cannot be exercised end-to-end without a real publish; the next release is its first live run.