Wait for npm to serve the version before registering it

[jeremiahsay]

1.0.4 shipped to npm on 15 September and the MCP registry stayed on 1.0.3 for a day. The registry job had failed, and nothing said so.

What happened

run 34917975455 · 15 Sep 01:37 UTC
  ✓ npm           18s
  X MCP registry  14s

  400: NPM package 'greencalculus-mcp' exists, but version '1.0.4'
       was not found (status: 404)

The registry validates a packages[] entry by fetching that exact version from npm, and npm's read API lags its own publish. The registry job asked at 01:37:39; npm began serving 1.0.4 at 01:38:14. Thirty-five seconds.

needs: npm was already there, so ordering was never the bug — the precondition is npm serving the version, not having published it.

Three changes

1. Wait for npm to serve it (20 × 15s). Placed before the login, deliberately: the registry session is short-lived, so login and publish have to stay adjacent — waiting after logging in would trade this failure for an expired-token one.
2. Retry the publish three times, with a fresh login each attempt for the same reason.
3. Say plainly what is inconsistent when it fails. This is the part that actually cost the day. When this job fails the npm job goes green beside it, the v1.0.4 tag is cut, the GHCR image builds, and Glama publishes its own 1.0.4 an hour later — every visible signal says the release landed, and only reading the registry back shows otherwise. On failure the step summary now states what is actually true, how to fix it, and the API call that adjudicates.

State right now

Already repaired out of band by a workflow_dispatch — the registry reads v1.0.4, isLatest: true, pinning greencalculus-mcp@1.0.4, updated 2026-09-16T00:54:17. This PR is so 1.0.5 does not repeat it.

Worth noting the workflow's weekly cron: 31 6 * * 1 would have healed this on its own, since both jobs check before they act — but not until Monday 21 September, five days late.

🤖 Generated with Claude Code

https://claude.ai/code/session_01NRueWxopDXHoWY2dPvsmLG