npm publish loop is not resumable: a partial publish failure forces a version bump

Locate the workflow step named npm-build-publish and inspect its platform publish loops, the PLATFORMS definition, and the hyperdb-api-node loop. First reproduce the current behavior from the workflow configuration and package paths. Done means a partial publish can be safely re-run, availability failures are detected, and platform definitions are not duplicated.

Summary

The npm platform-package publish loops abort on the first already-published package, so a partial publish cannot be recovered by re-running the job. This turned a transient registry failure during v1.0.0-rc.2 into a situation with no re-run path.

What happened during v1.0.0-rc.2

npm-build-publish completed successfully — every job green, and the log shows a normal tarball summary plus the confirmation line + hyperdb-mcp-linux-x64-gnu@1.0.0-rc.2. But that package never became available on the registry.

Confirmed absent by four independent routes, ~50 minutes after publish:

• GET /hyperdb-mcp-linux-x64-gnu/1.0.0-rc.2 → 404
• the full packument returns 200 and lists nothing newer than 1.0.0-rc.1
• that packages rc dist-tag still points at 1.0.0-rc.1
• HEAD on its tarball URL → 404, while the equivalent sibling URL → 200

Its siblings published immediately before and after it were both live within about five minutes. The likely cause is npms asynchronous post-publish processing silently failing to complete — the job log carries npms own "Your package is being processed and may take a few minutes to become available" warning, and this was the largest of the three tarballs at 87.4 MB compressed / 281 MB unpacked. The upload was accepted; the registry never finished making it available.

Why it cannot be re-run

set -euo pipefail
for dir in hyperdb-mcp/npm/darwin-arm64 hyperdb-mcp/npm/linux-x64-gnu hyperdb-mcp/npm/win32-x64-msvc; do
  cd "$dir"
  npm publish --access public --tag "$NPM_TAG"
  cd -
done

darwin-arm64 is published first and already exists at 1.0.0-rc.2, so a re-run gets E403 You cannot publish over the previously published versions and set -e aborts the step before it reaches linux-x64-gnu. The hyperdb-api-node loop has the same shape.

So the only recovery paths are a manual one-off publish or cutting a new version — for a failure in a single package that the workflow itself reported as successful.

Impact of this instance

hyperdb-mcp@1.0.0-rc.2 is live and pins hyperdb-mcp-linux-x64-gnu at exactly 1.0.0-rc.2 in optionalDependencies, and the rc dist-tag now points at it. Because the dependency is optional, npm install hyperdb-mcp@rc on Linux x64 appears to succeed and then fails at launch with Could not find hyperdb-mcp binary for linux-x64. macOS arm64 and Windows x64 are unaffected, hyperdb-api-node published completely on all three platforms, and the latest tag still resolves to 0.7.3 — so only consumers who opt into @rc on Linux x64 are affected.

Suggested fix

Make each publish idempotent so the step is resumable, e.g. skip when the exact version already exists:

if npm view "$PKG@$VERSION" version >/dev/null 2>&1; then
  echo "$PKG@$VERSION already published, skipping"
else
  npm publish --access public --tag "$NPM_TAG"
fi

Two related hardening ideas worth considering in the same change:

1. Verify availability, not just exit status. The step should poll the registry for each published version before declaring success, since this failure mode produces a zero exit code and a success log while the package is unreachable.
2. Collapse the duplicated platform lists. The workflow comment states PLATFORMS is "the SINGLE source of truth for which platforms ship", but the publish loops then hardcode the same three paths again — so there are two sources that must be kept in step. Driving the loops from PLATFORMS would remove the drift risk the comment warns about.