fix(release): bound the registry-publish verification retry window

[cdeust]

Summary

• v3.1.1 released successfully (PyPI, GitHub Release, and MCP Registry with isLatest=true all agree at 16:48:46), but the publish-registry job's last step, "Verify the registry now serves the published version", still reported failure: it read the registry one second later (16:48:47) with zero retry tolerance and hit the registry's own CDN cache layer before it converged (source: modelcontextprotocol/registry docs/design/tech-architecture.md, "CDN Layer" — "Caches all public read endpoints").
• Fix: bounded retry, 12 attempts x 5s = 60s, before concluding non-convergence. The bound is a stated engineering assumption (no published cache-TTL SLA), an order of magnitude above the 1s staleness actually observed. It still fails, with the same message, when the registry genuinely never serves the expected version.
• Also fixes the workflow_dispatch recovery path: mcp-publisher publish returning cannot publish duplicate version means the registry already has the version — the desired end state for a recovery re-run — but that swallow is scoped to workflow_dispatch only and is still independently confirmed by the verify step. On the normal push-tag path the same error stays fatal (this job runs once per tag, gated on needs: [test, release]), and any other publish error on either path fails immediately without touching the retry window.

Test plan

• python3 -c "import yaml; yaml.safe_load(...)" — YAML parses.
• actionlint .github/workflows/Release.yaml — clean, no findings.
• Simulated the retry loop against the live registry API (registry.modelcontextprotocol.io/v0/servers?search=hypermnesia-mcp-viz): converges on attempt 1 for the real current version (3.1.1), and correctly exhausts all attempts and fails for a version that will never match (99.99.99).
• Simulated the publish-step duplicate-handling branch for all 5 cases (push+duplicate, dispatch+duplicate, push+other-error, dispatch+other-error, success) — only dispatch+duplicate is swallowed; every other failure exits immediately.
• Live CI run on the next tag push / workflow_dispatch (cannot run in this session — no container/full-suite execution per machine-load constraint; requester will watch CI).

🤖 Generated with Claude Code

[cdeust]

ZETETIC-REVIEW: APPROVE

This repairs a gate that failed on a success, which is the direction nobody watches and the one that gets gates disarmed. v3.1.1 published correctly — PyPI 3.1.1, GitHub release, registry serving 3.1.1 as isLatest at 16:48:46 — and the workflow reported failure because the verification read the registry at 16:48:47 and saw the pre-publish cached entry.

The cause is identified, not guessed: the registry sits behind a CDN, per modelcontextprotocol/registry's own docs/design/tech-architecture.md. And the proof that publication had genuinely succeeded is external — re-dispatching returned 400 — cannot publish duplicate version. The registry already had it.

The bound is stated as an assumption rather than dressed as a measurement, which is the right call and the harder one. Twelve attempts at five seconds is sixty seconds, sized an order of magnitude above the only empirical figure available (staleness still present one second after publish); no cache-TTL SLA is published, and the PR says so instead of inventing a number and attributing it to a source.

The two properties that had to survive, did. The loop still exits non-zero when the registry never converges — a timeout, not a retry-until-pass — and the publish step's own failure still fails the job immediately without waiting out the window. A retry that always passes is a deleted check wearing a loop, and this is not one.

The duplicate case is distinguished rather than swallowed. cannot publish duplicate version is tolerated only on workflow_dispatch, where "already published" is the desired end state, and even then only as a candidate: the verify step still re-queries independently and fails on disagreement. On the push path the same error stays fatal, because that job runs once per tag and an existing entry there means something is wrong.

Verified in the agent's own thread rather than deferred: the retry loop was run against the live registry, converging on attempt 1 for the real current version and correctly exhausting its window for a version chosen never to match. All five publish-step branches were simulated; only dispatch-plus-duplicate is swallowed.

On the two red test jobs: they were a network timeout reaching registry.modelcontextprotocol.io/v0/validate from CI — 1335 tests passed, and the failure was in a step that calls a live third-party API. Re-running turned them green, and main shows four consecutive successes, so this is not the diff. It is worth saying plainly that a required check depending on a live external endpoint will keep doing this, and that ci.yml pins mcp-publisher at v1.7.9 while Release.yaml pins v1.8.1 — two pins of one tool, already diverged. Both are real and both belong in their own change, not smuggled into this one.

Merging.