The Releaser marks a release failed whenever npm takes longer than two minutes to show the new version, even though the package was published. Every such run then skips Build Release Binaries and Create GitHub Release, so the version ships to npm with no GitHub release and no binaries.
Evidence: the last ten release runs
| Version | Run | pantry publish public readback | On npm |
|---|---|---|---|
| 0.3.28 | failure | 120.0s, then exit 1 | yes, ~4 min after upload |
| 0.3.27 | failure | 120.0s, then exit 1 | yes, ~3 min after upload |
| 0.3.26 | success | 58.4s | yes |
| 0.3.25 | failure | 120.0s, then exit 1 | yes |
| 0.3.24 | failure | 120.0s, then exit 1 | yes |
| 0.3.23 | success | 61.6s | yes |
| 0.3.22 | success | 72.0s | yes |
| 0.3.21 | success | 58.2s | yes |
| 0.3.20 | failure | 120.0s, then exit 1 | yes |
| 0.3.19 | success | 59.1s | yes |
Every failed run logs the same thing after a successful upload:
timings: public readback 120.0s
Upload accepted; publication is pending public metadata and verified tarball availability. Do not upload this version again.
##[error]Process completed with exit code 1.The package is always published. What fails is pantry publish's own wait to read it back from the public registry: it gives up at 120 seconds and exits 1, and npm's propagation delay is often longer. As a result, 0.3.20, 0.3.24, 0.3.25, 0.3.27 and 0.3.28 have no GitHub release; the latest one listed is 0.3.26.
Re-running the failed job is not a fix. It would upload the same version again, which the publisher warns against ("Do not upload this version again") and which can produce a staged-version conflict.
Proposed fix
pantry's own Releaser already handles this. Its docs/releases.md ("npm acceptance and public availability") documents the contract, and .github/workflows/release.yml implements it:
- Publish once and keep the result. Run
pantry publish --npm --access publiconce, tee its output to a log, and keep its exit code. - Read back for longer, with full checks. Pass that exit code to
.github/scripts/npm-publication-readback.ts. A pending accepted upload continues to a bounded readback of up to 15 minutes, which checks the real archive: the original identity, the metadata checksums, the full tarball bytes, and the manifest inside the archive. - Fail only on real problems. A rejected upload, a missing or conflicting receipt, or a mismatched archive still fails the job; a slow registry no longer does. The publish log and proof are kept as artifacts.
Adopting the same step here, before Build Release Binaries and Create GitHub Release, would let a slow npm finish the release instead of abandoning it.
Also needed
Create the missing GitHub releases (and binaries) for 0.3.20, 0.3.24, 0.3.25, 0.3.27 and 0.3.28 from their existing tags, without publishing to npm again.
Found while releasing 0.3.28 for stacksjs/bun-query-builder#1196.