Merge timeout fix PR #1142 to stop supermemory MCP stalls

[Dhravya]

Problem

Outbound requests from the supermemory-mcp Durable Object to api.supermemory.ai had no client-side timeout, causing stalls of up to ~318 seconds when downstream services (Turbopuffer, Gemini) were slow. Two code paths were affected:

1. SDK calls (search, add, forget, profile) — the Supermemory SDK client was constructed without a timeout option.
2. Manual fetch calls (getProjects, getDocuments, auth endpoints, OAuth metadata proxy) — no signal or AbortSignal at all, meaning stalls could last indefinitely.

Changes

apps/mcp/src/client.ts

• Added FETCH_TIMEOUT_MS = 30_000 constant
• Passed timeout: FETCH_TIMEOUT_MS to the Supermemory SDK constructor to bound all SDK-backed calls
• Added options?: { signal?: AbortSignal } to getProjects and getDocuments, defaulting to AbortSignal.timeout(FETCH_TIMEOUT_MS)
• Extended handleError to catch AbortError / TimeoutError and surface a friendly "Request to Supermemory API timed out" message

apps/mcp/src/auth.ts

• Added signal: AbortSignal.timeout(30_000) to the validateOAuthToken fetch call

apps/mcp/src/index.ts

• Added signal: AbortSignal.timeout(30_000) to the OAuth authorization server metadata proxy fetch

Assumptions

• 30 seconds is an appropriate upper bound for MCP tool calls (matches the existing timeout constant pattern used elsewhere in the repo).
• Callers in server.ts do not currently have a per-request AbortSignal from the McpAgent/ExecutionContext, so the options parameter serves as an extension point for future use; all existing call sites pick up the 30-second default automatically.
• Pre-existing type errors in unrelated packages (@supermemory/tools) are not caused by this change — the MCP package itself has no new type errors.

Closes the latency anomaly reported in Polylane investigation fix_ee52cb420001xem6qyi2tc7t.

  

---

Session Details

• Session: View Session
• Requested by: Mahesh Sanikommu (mahesh@supermemory.com)
• Address comments on this PR. Add (aside) to your comment to have me ignore it.

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Updated (UTC)
✅ Deployment successful! View logs	supermemory-mcp	790f989	Jun 22 2026, 06:05 AM

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	supermemory-app	790f989	Commit Preview URL Branch Preview URL	Jun 22 2026, 06:07 AM

[vorflux]

Found one blocking gap: the OAuth auth path gets a timeout, but the API-key auth path still does not, so API-key MCP requests can still stall before any of the new client/SDK timeouts apply.

---

Review with Vorflux

[claude]

Claude finished @MaheshtheDev's task in 1m 4s —— View job

---

Reviewing PR #1143

• Get PR diff and review changes
• Verify previous review issues have been addressed
• Check for any remaining bugs or security issues
• Post review summary

---

Overview: Adds 30-second fetch timeouts across all MCP outbound requests and returns retryable 504 errors on auth stalls.

Issues found: None — this looks good to ship.

The previous review gaps have been addressed:

• ✅ validateApiKey() now has signal: AbortSignal.timeout(FETCH_TIMEOUT_MS) at auth.ts:49
• ✅ Auth timeouts return 504 with JSON-RPC error instead of 401 (addresses the retryability concern)
• ✅ Shared constant FETCH_TIMEOUT_MS used consistently across all four files
• ✅ AuthValidationResult type properly distinguishes success | invalid | timeout states
• ✅ handleError in client.ts catches APIConnectionTimeoutError, AbortError, and TimeoutError

The implementation is clean and consistent:

• Both validateApiKey() and validateOAuthToken() use identical timeout patterns
• SDK client is configured with timeout and maxRetries: 0
• Manual fetches in getProjects(), getDocuments(), and OAuth metadata proxy all have timeout signals

Score: 10/10 — All identified gaps from prior reviews are fixed. No bugs, no security issues, clean logic.

[claude]

Overview: Adds 30-second fetch timeouts to prevent MCP stalls from slow downstream services.

Issues found:

The previous review correctly identified a gap: validateApiKey() in apps/mcp/src/auth.ts:30-35 still lacks a timeout signal, while validateOAuthToken() now has one. Since handleMcpRequest() calls validateApiKey() before constructing the SupermemoryClient, API-key authenticated MCP requests can still hang indefinitely during auth — the new SDK/client timeouts never get a chance to apply.

Fix needed: Add signal: AbortSignal.timeout(30_000) to the fetch in validateApiKey(), matching the pattern used in validateOAuthToken(). Consider extracting the timeout constant to a shared location if not already done.

Everything else looks solid:

• SDK constructor timeout ✓
• getProjects/getDocuments default signals ✓
• handleError catches AbortError/TimeoutError ✓
• OAuth metadata proxy timeout ✓

Score: 7/10 — One auth path still exposed to the original stall bug. Once that's fixed, this is ready to ship.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 3d5579a006

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".