Skip to content

fix(release): wait for npm to list the release before publishing the MCP Registry entry - #3444

Merged
thymikee merged 1 commit into
mainfrom
fix/mcp-registry-await-npm
Oct 11, 2026
Merged

thymikee merged 1 commit into
mainfrom
fix/mcp-registry-await-npm

Conversation

@thymikee

@thymikee thymikee commented Oct 11, 2026 •

Copy link
Copy Markdown
Member

Summary

The MCP Registry job ran five seconds after the npm publish in the v0.21.25 release and failed: the registry validates the server's npm package, and npm had not listed agent-device@0.21.25 yet ("version not found… wait and retry"). Re-running the job passed.

publish-mcp-registry.yml now waits, before authenticating, until registry.npmjs.org/<package> lists the release version. It polls every 15 s for up to 10 minutes, then fails with an error that names the missing version. The job timeout grows from 10 to 20 minutes to fit the wait. The check reads the root package name from package.json, the package the registry validates first. One workflow file changed.

Validation

51a4ef2a79 (this head): pnpm check:affected --run passed; actionlint clean. The listing check, run against the live registry, exits 0 for agent-device@0.21.25 and 1 for an unpublished version. The release path itself runs only on the next stable release.

View guided diff Turn on auto-fix

@github-actions

Copy link
Copy Markdown
Contributor

Size Report

Metric Base Current Diff
Installed (including dependencies) 5.17 MB 5.17 MB 0 B
Package (unpacked) 5.17 MB 5.17 MB 0 B
Package (download) 1.55 MB 1.55 MB +18 B

Startup median (7 runs, lower is better):

Scenario Base Current Diff
CLI --version 23.1 ms 22.9 ms -0.2 ms
CLI --help 64.5 ms 60.9 ms -3.6 ms

@cubic-dev-ai cubic-dev-ai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

1 issue found across 1 file

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. When an issue isn't valid or won't be fixed in this PR, reply in its thread with the reason and then resolve the thread. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name=".github/workflows/publish-mcp-registry.yml">

<violation number="1" location=".github/workflows/publish-mcp-registry.yml:86">
P3: This poll loop is only bounded if each `curl` completes, but `curl` has no timeout by default: a hung registry response stalls the iteration indefinitely, and with up to 40 iterations the step can silently consume the whole 20-minute job budget instead of the intended ~10-minute poll. Add `--max-time 30` so slow or dead connections fail the attempt and fall through to the `sleep 15` retry.</violation>
</file>

Reply with feedback, questions, or to request a fix.

View guided diff | Turn on auto-fix | Re-trigger cubic

package="$(node -p "require('./package.json').name")"
version="${RELEASE_TAG#v}"
for _ in $(seq 1 40); do
if curl --fail --silent --show-error "https://registry.npmjs.org/${package}" \

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P3: This poll loop is only bounded if each curl completes, but curl has no timeout by default: a hung registry response stalls the iteration indefinitely, and with up to 40 iterations the step can silently consume the whole 20-minute job budget instead of the intended ~10-minute poll. Add --max-time 30 so slow or dead connections fail the attempt and fall through to the sleep 15 retry.

Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. When an issue isn't valid or won't be fixed in this PR, reply in its thread with the reason and then resolve the thread. At .github/workflows/publish-mcp-registry.yml, line 86:

<comment>This poll loop is only bounded if each `curl` completes, but `curl` has no timeout by default: a hung registry response stalls the iteration indefinitely, and with up to 40 iterations the step can silently consume the whole 20-minute job budget instead of the intended ~10-minute poll. Add `--max-time 30` so slow or dead connections fail the attempt and fall through to the `sleep 15` retry.</comment>

<file context>
@@ -73,6 +73,27 @@ jobs:
+          package="$(node -p "require('./package.json').name")"
+          version="${RELEASE_TAG#v}"
+          for _ in $(seq 1 40); do
+            if curl --fail --silent --show-error "https://registry.npmjs.org/${package}" \
+              | node -e 'let s="";process.stdin.on("data",(c)=>(s+=c)).on("end",()=>process.exit(JSON.parse(s).versions?.[process.argv[1]]?0:1))' "$version"; then
+              echo "${package}@${version} is listed on npm."
</file context>
Suggested change
if curl --fail --silent --show-error "https://registry.npmjs.org/${package}" \
if curl --fail --silent --show-error --max-time 30 "https://registry.npmjs.org/${package}" \

@thymikee

Copy link
Copy Markdown
Member Author

This PR is ready: I found no problems in 51a4ef2.

Not blocking, and you can take or leave it: the wait step at .github/workflows/publish-mcp-registry.yml#L86 polls the full packument (registry.npmjs.org/<package>), and I believe the MCP Registry validator reads the per-version document (registry.npmjs.org/<package>/<version>), which the CDN serves as a separate entry. I have not verified that, so would polling curl --fail --silent --show-error --max-time 20 "https://registry.npmjs.org/${package}/${version}" and treating HTTP 200 as listed be simpler? It would also drop the node JSON parse and the repeated full-packument downloads, and the --max-time covers the hung-request case below.

The Cubic P3 thread still applies: curl has no --max-time, so one hung response uses up the job timeout instead of showing your ::error:: message (#3444 (comment)). Adding --max-time 30 fixes it and keeps the 10-minute bound.

Smoke Tests failed in the live iOS simulator fixture E2E, where a depth-1 snapshot came back sparse. This PR only changes publish-mcp-registry.yml, which the stable-release path in release.yml calls. It does not touch the runner, the snapshot code, the fixture app or the Smoke Tests job, so the failure looks unrelated. Please rerun that job. There are no conflicts.

I did not run the wait loop against the live registry, and I did not check how long npm takes to list a version, so the 10-minute budget rests on your observation at v0.21.25. The next stable release is the first real run of this path, and a workflow_dispatch rerun against an already-listed tag would exercise the early-exit branch. Nothing else stands in the way of merging once Smoke Tests passes on rerun.

@thymikee thymikee added the ready-for-human Valid work that needs human implementation, judgment, or maintainer merge label Oct 11, 2026
@thymikee
thymikee merged commit b15c7c7 into main Oct 11, 2026
18 of 19 checks passed
@thymikee
thymikee deleted the fix/mcp-registry-await-npm branch October 11, 2026 19:01
@github-actions

Copy link
Copy Markdown
Contributor
PR Preview Action v1.8.1
Preview removed because the pull request was closed.
2026-10-11 19:01 UTC

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

ready-for-human Valid work that needs human implementation, judgment, or maintainer merge

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant