Add request timeouts to Supermemory MCP client calls#1146
Conversation
- Set timeout: 30_000 on the Supermemory SDK constructor so all SDK method calls (add, memories.forget, search.memories, profile) time out after 30 s instead of hanging indefinitely. - Add signal: AbortSignal.timeout(30_000) to the two manual fetch helpers getProjects and getDocuments. - Handle AbortError / TimeoutError in handleError so a timed-out request surfaces a clear message instead of propagating an unhandled exception into the Durable Object. Co-authored-by: Dhravya Shah <dhravya@supermemory.com>
Co-authored-by: Dhravya Shah <dhravya@supermemory.com>
Deploying with
|
| Status | Name | Latest Commit | Updated (UTC) |
|---|---|---|---|
| ✅ Deployment successful! View logs |
supermemory-mcp | c33c904 | Jun 20 2026, 09:39 PM |
Deploying with
|
| Status | Name | Latest Commit | Preview URL | Updated (UTC) |
|---|---|---|---|---|
| ✅ Deployment successful! View logs |
supermemory-app | c33c904 | Commit Preview URL Branch Preview URL |
Jun 20 2026, 09:40 PM |
|
Claude finished @MaheshtheDev's task in 1m 27s —— View job Reviewing PR #1146: Add request timeouts to Supermemory MCP client calls
SummaryReviewed the timeout implementation in
No bugs, security issues, or logic errors found. Score: 10/10 — ready to ship. |
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
There was a problem hiding this comment.
Overview: Adds 30-second request timeouts to all Supermemory MCP client calls (SDK constructor + manual fetch helpers) with proper error handling.
Issues found: None — this looks good to ship.
The implementation is clean and correct:
timeout: 30_000on the SDK constructor covers all SDK method calls (add,memories.forget,search.memories,profile)AbortSignal.timeout(30_000)on the two manual fetch calls (getProjects,getDocuments) is the correct pattern for Cloudflare Workers- Error handling properly intercepts both
AbortErrorandTimeoutError(theDOMExceptionname used byAbortSignal.timeout) and converts them to user-friendly messages - The error handler is correctly placed at the start of
handleErrorso timeout errors are caught before other checks
The PR description accurately notes that SDK retries (2 by default) could extend worst-case latency to ~90s, which is documented and acceptable given the tradeoff against reliability.
Score: 10/10
3 participants
Summary
Fixes recurring
supermemory-mcpDurable Object latency spikes caused by outbound fetch calls tohttps://api.supermemory.ai(and downstream services like Turbopuffer and Gemini) stalling indefinitely, which in turn blocked parentsupermemoryWorker jsrpc spans for tens of seconds to minutes.Changes (
apps/mcp/src/client.tsonly)SDK client timeout
Added
timeout: 30_000(30 s) to theSupermemoryconstructor. The SDK'sClientOptions.timeoutfield applies to every request made through the client (add,memories.forget,search.memories,profile), so a single change covers all SDK method calls.Manual fetch helpers
Added
signal: AbortSignal.timeout(30_000)to the two manualfetchcalls ingetProjectsandgetDocuments. These helpers bypass the SDK and hit/v3/projects//v3/documents/documentsdirectly, so they need their own timeout signal.AbortError handling
Extended the existing
handleErrormethod to interceptAbortErrorandTimeoutError(theDOMExceptionname used byAbortSignal.timeout) and convert them to a clean user-facing message instead of letting the raw exception propagate into the Durable Object.Assumptions & notes
AbortErrorsurfaces, meaning total worst-case wait per SDK call is ~90 s. This is still dramatically better than the unbounded stall seen in production and avoids unnecessarily degrading reliability for transient network hiccups. Retries can be disabled (maxRetries: 0) if stricter latency bounds are required.AbortSignal.timeoutis available in the Cloudflare Workers runtime (same as Node ≥ 17).server.ts(MCP SDK version mismatch) andmcp-app.ts(DOM lib) are unrelated to this change and were present before.