[GH-ISSUE #4998] [Bug] 6.7.0 MCP Registry publication blocked by registry read timeouts #3086

Closed
opened 2026-10-31 00:36:21 +00:00 by bsakaguchi · 5 comments
Owner

Originally created by @morluto on GitHub (Oct 18, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/4998

Before submitting

  • Searched open and closed reports for MCP Registry publication timeouts; no matching release report found.
  • Evidence contains no credentials or sensitive target data.

Area

Setup, packaging, or upgrade

Observed behavior

6.7.0 is published on npm as latest. Full exact-source qualification, clean-runner tarball rehearsal, integrity/dist-tag verification, installed CLI/MCP checks (207 tools), and the real 6.5.0-to-6.7.0 update canary passed. MCP Registry publication stops before authentication because its existing-version GET times out.

Both original job 117625693260 and failed-job retry 117626193495 fail with Node TimeoutError after 30 seconds in .github/actions/publish-mcp/registry-state.mjs:24. Metadata validation passes; authentication and POST publication are skipped.

Reproduction

Observed in two CI attempts at the same release source and independent public requests. IPv4 curl requests to the filtered listing, version history, exact-version read, unfiltered listing (/v0.1/servers?limit=1), and unrelated filesystem search received zero bytes before their 15–20 second bounds. /v0.1/ping returned 200. A separate Node 24 lookup also timed out at 30 seconds.

Expected behavior

Registry reads must return authoritative metadata before the guarded publisher can decide whether this exact active version already exists. Unknown state must remain unknown; do not skip lookup or infer absence from timeout. After read service recovers, rerun only failed jobs in original release run 39108764422 and verify active metadata matches the released server.json.

Impact and scope

Only MCP Registry publication remains pending. The npm package and GitHub release (including the full finalized 6.6.0 changelog) are available. No npm republish, tag movement, registry authentication, or MCP POST was attempted after this failure.

REA version

6.7.0, immutable tag source 27dc42d10249f0410904a75c0997842eb03b931c.

Runtime and platform

CI: Ubuntu, registry helper on Node 22.23.3. Independent checks: macOS arm64, Node 24.18.0 and IPv4 curl. Source/runtime qualification used pinned Node 24.18.0.

Target and artifact context

Public server io.github.morluto/rea, MCP version 6.7.0, npm package rea-agents@6.7.0. Original release run 39108764422 retains its qualified package and successful npm canary.

Interface

Other

Earliest failure stage

Transport or result projection

Relevant output or evidence

DOMException [TimeoutError]: The operation was aborted due to timeout in registryPublicationState before authentication. Public listing query: https://registry.modelcontextprotocol.io/v0.1/servers?search=io.github.morluto%2Frea&version=6.7.0&include_deleted=true&limit=100. Additional independent probes omitted version filtering and used other documented read routes, with the same timeout. Upstream API contract.

Typed outcome and error chain

No analysis Evidence involved. Raw HTTP timeout, failed MCP publication job, npm publication independently verified successful.

Analysis or suspected cause

Observed: the service responds to liveness/validation requests while metadata reads do not complete. NOT_ENOUGH_INFO: upstream cause and recovery time are unknown. No repository code fix, timeout increase, safety-check bypass, or blanket retry policy has been introduced.

Originally created by @morluto on GitHub (Oct 18, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/4998 ### Before submitting - [x] Searched open and closed reports for MCP Registry publication timeouts; no matching release report found. - [x] Evidence contains no credentials or sensitive target data. ### Area Setup, packaging, or upgrade ### Observed behavior 6.7.0 is published on npm as latest. Full exact-source qualification, clean-runner tarball rehearsal, integrity/dist-tag verification, installed CLI/MCP checks (207 tools), and the real 6.5.0-to-6.7.0 update canary passed. MCP Registry publication stops before authentication because its existing-version GET times out. Both original [job 117625693260](https://github.com/morluto/rea/actions/runs/39108764422/job/117625693260) and failed-job retry [117626193495](https://github.com/morluto/rea/actions/runs/39108764422/job/117626193495) fail with Node TimeoutError after 30 seconds in `.github/actions/publish-mcp/registry-state.mjs:24`. Metadata validation passes; authentication and POST publication are skipped. ### Reproduction Observed in two CI attempts at the same release source and independent public requests. IPv4 curl requests to the filtered listing, version history, exact-version read, unfiltered listing (`/v0.1/servers?limit=1`), and unrelated filesystem search received zero bytes before their 15–20 second bounds. `/v0.1/ping` returned 200. A separate Node 24 lookup also timed out at 30 seconds. ### Expected behavior Registry reads must return authoritative metadata before the guarded publisher can decide whether this exact active version already exists. Unknown state must remain unknown; do not skip lookup or infer absence from timeout. After read service recovers, rerun only failed jobs in original release run 39108764422 and verify active metadata matches the released server.json. ### Impact and scope Only MCP Registry publication remains pending. The npm package and GitHub release (including the full finalized 6.6.0 changelog) are available. No npm republish, tag movement, registry authentication, or MCP POST was attempted after this failure. ### REA version 6.7.0, immutable tag source `27dc42d10249f0410904a75c0997842eb03b931c`. ### Runtime and platform CI: Ubuntu, registry helper on Node 22.23.3. Independent checks: macOS arm64, Node 24.18.0 and IPv4 curl. Source/runtime qualification used pinned Node 24.18.0. ### Target and artifact context Public server `io.github.morluto/rea`, MCP version 6.7.0, npm package rea-agents@6.7.0. Original release run 39108764422 retains its qualified package and successful npm canary. ### Interface Other ### Earliest failure stage Transport or result projection ### Relevant output or evidence `DOMException [TimeoutError]: The operation was aborted due to timeout` in registryPublicationState before authentication. Public listing query: `https://registry.modelcontextprotocol.io/v0.1/servers?search=io.github.morluto%2Frea&version=6.7.0&include_deleted=true&limit=100`. Additional independent probes omitted version filtering and used other documented read routes, with the same timeout. [Upstream API contract](https://github.com/modelcontextprotocol/registry/blob/main/docs/reference/api/openapi.yaml). ### Typed outcome and error chain No analysis Evidence involved. Raw HTTP timeout, failed MCP publication job, npm publication independently verified successful. ### Analysis or suspected cause Observed: the service responds to liveness/validation requests while metadata reads do not complete. NOT_ENOUGH_INFO: upstream cause and recovery time are unknown. No repository code fix, timeout increase, safety-check bypass, or blanket retry policy has been introduced.
bsakaguchi 2026-10-31 00:36:21 +00:00
  • closed this issue
  • added the
    triage
    bug
    labels
Author
Owner

@XinwangTao commented on GitHub (Oct 18, 2026):

The liveness-vs-metadata divergence (ping 200 while every listing/history read times out) points at an upstream data-plane issue rather than the registry being down wholesale — so the guarded-publisher semantics you kept (unknown stays unknown, never infer absence from timeout) is exactly right, and it also means a blanket retry on the POST path would have been unsafe. Two cheap hardening ideas for the helper while waiting on upstream: (1) classify the read failure (TimeoutError vs 5xx vs 404) and emit it in the job summary so the next rerun can tell "registry degraded" from "route changed"; (2) add a small bounded backoff (e.g. 2 retries with 5s/15s delay) only around the existing-version GET, since that read is the single gate before authentication — it makes the publish job self-healing on short blips without changing the unknown-state rule. Rerunning only the failed jobs in 39108764422 afterwards and diffing server.json against released metadata is the right completion check.

<!-- gh-comment-id:6247595639 --> @XinwangTao commented on GitHub (Oct 18, 2026): The liveness-vs-metadata divergence (ping 200 while every listing/history read times out) points at an upstream data-plane issue rather than the registry being down wholesale — so the guarded-publisher semantics you kept (unknown stays unknown, never infer absence from timeout) is exactly right, and it also means a blanket retry on the POST path would have been unsafe. Two cheap hardening ideas for the helper while waiting on upstream: (1) classify the read failure (TimeoutError vs 5xx vs 404) and emit it in the job summary so the next rerun can tell "registry degraded" from "route changed"; (2) add a small bounded backoff (e.g. 2 retries with 5s/15s delay) only around the existing-version GET, since that read is the single gate before authentication — it makes the publish job self-healing on short blips without changing the unknown-state rule. Rerunning only the failed jobs in 39108764422 afterwards and diffing server.json against released metadata is the right completion check.
Author
Owner

@Rintu62 commented on GitHub (Oct 18, 2026):

Hi I'd like to work on the hardening side of this, if you're open to a PR.
Based on the issue and XinwangTao's suggestion, I'm planning to scope it to .github/actions/publish-mcp/registry-state.mjs only:

  1. Classify the read failure (TimeoutError vs 5xx vs 404) and surface it in the job summary, so a rerun can tell "registry degraded" from "route changed".
  2. Add a small bounded retry/backoff (e.g. 2 retries, 5s/15s) around the existing-version GET only.
    The guarded-publisher semantics stay unchanged: unknown stays unknown, and absence is never inferred from a timeout. No changes to auth or the POST path.
    I'll include a mocked-timeout regression test and the check results in the PR body. Does this scope match what you want, or would you prefer a different approach?
<!-- gh-comment-id:6247911434 --> @Rintu62 commented on GitHub (Oct 18, 2026): Hi I'd like to work on the hardening side of this, if you're open to a PR. Based on the issue and XinwangTao's suggestion, I'm planning to scope it to `.github/actions/publish-mcp/registry-state.mjs` only: 1. Classify the read failure (TimeoutError vs 5xx vs 404) and surface it in the job summary, so a rerun can tell "registry degraded" from "route changed". 2. Add a small bounded retry/backoff (e.g. 2 retries, 5s/15s) around the existing-version GET only. The guarded-publisher semantics stay unchanged: unknown stays unknown, and absence is never inferred from a timeout. No changes to auth or the POST path. I'll include a mocked-timeout regression test and the check results in the PR body. Does this scope match what you want, or would you prefer a different approach?
Author
Owner

@RHMHY commented on GitHub (Oct 18, 2026):

I believe we can address this for registry GET requests by implementing a limited retry mechanism that includes a brief delay between attempts. If the registry continues to time out, the workflow should fail safely—rather than incorrectly assuming that a version does not exist or proceeding with a release attempt. To ensure that existing safety checks remain intact, we can also add regression tests covering scenarios such as intermittent timeouts, persistent failures, and successful recovery.

<!-- gh-comment-id:6248084103 --> @RHMHY commented on GitHub (Oct 18, 2026): I believe we can address this for registry GET requests by implementing a limited retry mechanism that includes a brief delay between attempts. If the registry continues to time out, the workflow should fail safely—rather than incorrectly assuming that a version does not exist or proceeding with a release attempt. To ensure that existing safety checks remain intact, we can also add regression tests covering scenarios such as intermittent timeouts, persistent failures, and successful recovery.
Author
Owner

@morluto commented on GitHub (Oct 18, 2026):

Closing as completed. The registry read API recovered, and only the failed MCP Registry job was retried in the original exact-source release run.

  • Publication job succeeded: https://github.com/morluto/rea/actions/runs/39108764422/job/117809389597
  • Publisher confirmed io.github.morluto/rea version 6.7.0.
  • Fresh public exact-version and unversioned listing reads both returned the active 6.7.0 record, structurally identical to server.json at immutable tag rea-agents-6.7.0 (27dc42d10249f0410904a75c0997842eb03b931c).
  • npm was not republished; no tag or version was moved.

The earlier timeout cause remains unknown. This closes the release blocker; optional retry/diagnostic hardening proposals are separate follow-ups, not required to complete this publication.

<!-- gh-comment-id:6256044657 --> @morluto commented on GitHub (Oct 18, 2026): <!-- rea-backlog-reconciliation-2026-10-19-4998 --> Closing as completed. The registry read API recovered, and only the failed MCP Registry job was retried in the original exact-source release run. - Publication job succeeded: https://github.com/morluto/rea/actions/runs/39108764422/job/117809389597 - Publisher confirmed `io.github.morluto/rea` version `6.7.0`. - Fresh public exact-version and unversioned listing reads both returned the active 6.7.0 record, structurally identical to `server.json` at immutable tag `rea-agents-6.7.0` (`27dc42d10249f0410904a75c0997842eb03b931c`). - npm was not republished; no tag or version was moved. The earlier timeout cause remains unknown. This closes the release blocker; optional retry/diagnostic hardening proposals are separate follow-ups, not required to complete this publication.
Author
Owner

@RHMHY commented on GitHub (Oct 19, 2026):

Thank you for the detailed update and for resolving the release issue. It
is great to see that version 6.7.0 has been successfully released and
verified against an immutable release source. I appreciate the careful
handling of the retry process and the assurance that no unexpected changes
were introduced to the release or the npm package. Although the root cause
of the timeout remains unknown, the clear explanation provided was very
helpful.

Thank you for the transparent resolution and the verification steps taken.

On Mon, Oct 19, 2026, 4:09 AM morluto @.***> wrote:

Closed #4998 https://github.com/morluto/rea/issues/4998 as completed.

—
Reply to this email directly, view it on GitHub
https://github.com/morluto/rea/issues/4998?email_source=notifications&email_token=BMATUXTJJM3SLPBFWMMLXOL5UVBCJA5CNFSNUABQM5UWIORPF5TWS5BNNB2WEL2JONZXKZKFOZSW45CON52GSZTJMNQXI2LPNYXTGMZVHE3DANBXGM4THJTSMVQXG33OU5RW63LNMVXHJJLFOZSW45FMMZXW65DFOJPWG3DJMNVQ#event-33596047393,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BMATUXQ47IQDGSIQ6UAOC5D5UVBCJAVCNFSNUABGKJSXA33TNF2G64TZHMYTEMBZHE3DMOJTGM5US43TOVSTWNJZGA3TMMRQGIYTBILWAI
.
Triage notifications, keep track of coding agent tasks and review pull
requests on the go with GitHub Mobile for iOS
https://github.com/notifications/mobile/ios/BMATUXV4YXL5PMPZSV5XTFL5UVBCJA5CNFSNUABQM5UWIORPF5TWS5BNNB2WEL2JONZXKZKFOZSW45CON52GSZTJMNQXI2LPNYXTGMZVHE3DANBXGM4THJTSMVQXG33OU5RW63LNMVXHJJLFOZSW45FKMZXW65DFOJPWS33T
and Android
https://github.com/notifications/mobile/android/BMATUXS2TSQEWV5I2FGKEA35UVBCJA5CNFSNUABQM5UWIORPF5TWS5BNNB2WEL2JONZXKZKFOZSW45CON52GSZTJMNQXI2LPNYXTGMZVHE3DANBXGM4THJTSMVQXG33OU5RW63LNMVXHJJLFOZSW45FOMZXW65DFOJPWC3TEOJXWSZA.
Download it today!
You are receiving this because you commented.Message ID:
@.***>

<!-- gh-comment-id:6264072404 --> @RHMHY commented on GitHub (Oct 19, 2026): Thank you for the detailed update and for resolving the release issue. It is great to see that version 6.7.0 has been successfully released and verified against an immutable release source. I appreciate the careful handling of the retry process and the assurance that no unexpected changes were introduced to the release or the npm package. Although the root cause of the timeout remains unknown, the clear explanation provided was very helpful. Thank you for the transparent resolution and the verification steps taken. On Mon, Oct 19, 2026, 4:09 AM morluto ***@***.***> wrote: > Closed #4998 <https://github.com/morluto/rea/issues/4998> as completed. > > — > Reply to this email directly, view it on GitHub > <https://github.com/morluto/rea/issues/4998?email_source=notifications&email_token=BMATUXTJJM3SLPBFWMMLXOL5UVBCJA5CNFSNUABQM5UWIORPF5TWS5BNNB2WEL2JONZXKZKFOZSW45CON52GSZTJMNQXI2LPNYXTGMZVHE3DANBXGM4THJTSMVQXG33OU5RW63LNMVXHJJLFOZSW45FMMZXW65DFOJPWG3DJMNVQ#event-33596047393>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/BMATUXQ47IQDGSIQ6UAOC5D5UVBCJAVCNFSNUABGKJSXA33TNF2G64TZHMYTEMBZHE3DMOJTGM5US43TOVSTWNJZGA3TMMRQGIYTBILWAI> > . > Triage notifications, keep track of coding agent tasks and review pull > requests on the go with GitHub Mobile for iOS > <https://github.com/notifications/mobile/ios/BMATUXV4YXL5PMPZSV5XTFL5UVBCJA5CNFSNUABQM5UWIORPF5TWS5BNNB2WEL2JONZXKZKFOZSW45CON52GSZTJMNQXI2LPNYXTGMZVHE3DANBXGM4THJTSMVQXG33OU5RW63LNMVXHJJLFOZSW45FKMZXW65DFOJPWS33T> > and Android > <https://github.com/notifications/mobile/android/BMATUXS2TSQEWV5I2FGKEA35UVBCJA5CNFSNUABQM5UWIORPF5TWS5BNNB2WEL2JONZXKZKFOZSW45CON52GSZTJMNQXI2LPNYXTGMZVHE3DANBXGM4THJTSMVQXG33OU5RW63LNMVXHJJLFOZSW45FOMZXW65DFOJPWC3TEOJXWSZA>. > Download it today! > You are receiving this because you commented.Message ID: > ***@***.***> >
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
morluto/rea#3086
No description provided.