Repository navigation
fix(release): wait for npm to list the release before publishing the MCP Registry entry - #3444
Conversation
…MCP Registry entry
Size Report
Startup median (7 runs, lower is better):
|
There was a problem hiding this comment.
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}" \ |
There was a problem hiding this comment.
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>
| 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}" \ |
|
This PR is ready: I found no problems in 51a4ef2. Not blocking, and you can take or leave it: the wait step at The Cubic P3 thread still applies: curl has no Smoke Tests failed in the live iOS simulator fixture E2E, where a depth-1 snapshot came back sparse. This PR only changes 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 |
|
Summary
The MCP Registry job ran five seconds after the npm publish in the
v0.21.25release and failed: the registry validates the server's npm package, and npm had not listedagent-device@0.21.25yet ("version not found… wait and retry"). Re-running the job passed.publish-mcp-registry.ymlnow waits, before authenticating, untilregistry.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 frompackage.json, the package the registry validates first. One workflow file changed.Validation
51a4ef2a79(this head):pnpm check:affected --runpassed;actionlintclean. The listing check, run against the live registry, exits 0 foragent-device@0.21.25and 1 for an unpublished version. The release path itself runs only on the next stable release.