0.2.383 is the latest tag and its tarball 404s, so no fresh install of stx (or Stacks) resolves

@stacksjs/stx@0.2.383 is the latest dist-tag and its tarball returns 404, so no fresh install of stx (or of anything that depends on it, which includes the whole Stacks framework) can resolve.

The version exists in registry metadata and even records its tarball URL. Only the file is missing:

$ npm view @stacksjs/stx dist-tags --json
{ "latest": "0.2.383" }

$ npm view @stacksjs/stx@0.2.383 dist.tarball
https://registry.npmjs.org/@stacksjs/stx/-/stx-0.2.383.tgz

$ curl -o /dev/null -w "%{http_code}\n" https://registry.npmjs.org/@stacksjs/stx/-/stx-0.2.383.tgz
404

Three clients, same answer, so it is not one tool's cache:

$ npm install @stacksjs/stx
npm error 404

$ bun add @stacksjs/stx
error: GET https://registry.npmjs.org/@stacksjs/stx/-/stx-0.2.383.tgz - 404

$ npm pack @stacksjs/stx@0.2.383
npm error 404

Neighbouring versions are fine, so it is this one publish:

It takes the Stacks framework down with it

Every Stacks package declares "@stacksjs/stx": "^0.2.378", which resolves to the newest matching version, so a clean install picks 0.2.383 and fails:

$ bun add @stacksjs/buddy
Resolved, downloaded and extracted [292]
error: GET https://registry.npmjs.org/@stacksjs/stx/-/stx-0.2.383.tgz - 404

That is buddy new and any first install of the framework, on a machine with no lockfile and no cache. Existing checkouts are unaffected: stacksjs/stacks pins @stacksjs/stx@0.2.378 in bun.lock, so --frozen-lockfile keeps working and CI stays green. The breakage is invisible from inside the repository, which is how it can sit unnoticed.

This is the same shape as the v0.74.4 outage, where published packages pointed at versions whose publish had failed and buddy new was broken for six hours. The lesson recorded then was that a release is not done when the version numbers appear, only when the tarballs are fetchable.

Fix

Needs registry credentials, so I am not doing it:

1. Republish the 0.2.383 tarball if the artifact still exists, which keeps the version line intact; or
2. Move latest back to 0.2.382 (npm dist-tag add @stacksjs/stx@0.2.382 latest) and deprecate 0.2.383 so resolvers skip it, then cut 0.2.384 from the same source.

Option 2 is the faster unblock, and it works even while the 404 persists, because a range of ^0.2.378 will then resolve to 0.2.382.

Worth adding either way

A post-publish check that fetches every tarball it just announced before the release is called done. The registry accepting a version is not the same as the file being downloadable, and that gap is exactly what both this and the v0.74.4 outage were.

Resolved, and no republish was needed — the artifact was never missing. It was propagation, and it has now completed.

What actually happened

The publish succeeded. From the Releaser run's Publish stx step:

Publishing @stacksjs/stx@0.2.383...
  ✓ prepublishOnly completed
  Resolved @stacksjs/desktop: workspace:* → 0.2.383
  Resolved @stacksjs/sanitizer: workspace:* → 0.2.383
  Resolved bun-plugin-stx: workspace:* → 0.2.383
  Resolved stx-router: workspace:* → 0.2.383
Total files: 1027
Shasum: f9415d422414d177c9d0fcb7d53755ace47c51e5
Packed size: 2.04MB
✓ Sigstore provenance attached
✓ Published @stacksjs/stx@0.2.383 with provenance

That completed at 17:13:49Z. The packument did not catch up until 17:20:44Z — about seven minutes, during which versions had no 0.2.383 and the time map had no entry for it either. The tarball lagged further still. This issue was filed at 17:23:54Z, squarely inside that window.

@stacksjs/stx is by far the largest package in the release (1027 files, 2.04MB packed, 7.31MB unpacked); the other nine were all readable well before it. That ordering is consistent across releases and is worth knowing: the critical package is the slowest to propagate, so it is the one most likely to look broken.

One aggravating factor worth recording: requesting a tarball before it has propagated can cache the 404 at the CDN edge and extend the outage past the underlying replication. A cache-busting query string does not clear it, because the edge key is the path. So the correct response to a 404 here is to stop fetching it and read dist.shasum from the packument instead.

Verified now

$ curl -o stx383.tgz -w "%{http_code}" https://registry.npmjs.org/@stacksjs/stx/-/stx-0.2.383.tgz
200
$ shasum stx383.tgz
f9415d422414d177c9d0fcb7d53755ace47c51e5

Byte-identical to the shasum in the build log and to dist.shasum in the registry — so it is the artifact that run produced, not a re-upload.

Fresh install, isolated cache, no lockfile:

$ BUN_INSTALL_CACHE_DIR=$tmp/.cache bun add @stacksjs/stx@0.2.383
installed @stacksjs/stx@0.2.383 with binaries: stx
23 packages installed

$ BUN_INSTALL_CACHE_DIR=$tmp/.cache2 bun add @stacksjs/buddy
124 packages installed

The buddy path in the report — the one that matters for buddy new — resolves. Transitive versions all land at 0.2.383: @stacksjs/desktop, stx-router, bun-plugin-stx, @stacksjs/sanitizer.

On the two proposed fixes

Neither was the right action, and it is worth saying why. Republishing is not possible for a version npm already holds, and there was nothing wrong with the artifact to republish. Moving latest back to 0.2.382 would have rolled back the fixes for #2040 and #2041 — which stacksjs/system-cleaner is waiting on — to work around a condition that clears itself.

The diagnosis in the report was sound and the v0.74.4 comparison is apt. The refinement: a release is not done when the version numbers appear, and not when the tarball first 404s either — the tarball check has to be given time to pass before it is read as failure. Ten minutes is a normal propagation window for a package this size.