fix(mcp): return 503 on auth-backend outages instead of invalid_token - #1591
Conversation
Deploying with
|
| Status | Name | Latest Commit | Preview URL | Updated (UTC) |
|---|---|---|---|---|
| ✅ Deployment successful! View logs |
supermemory-app | 6cae175 | Commit Preview URL Branch Preview URL |
Aug 24 2026, 03:56 PM |
Deploying with
|
| Status | Name | Latest Commit | Updated (UTC) |
|---|---|---|---|
| ✅ Deployment successful! View logs |
supermemory-mcp | 6cae175 | Aug 24 2026, 03:55 PM |
How to use the Graphite Merge QueueAdd the label Main to this PR to add it to the merge queue. You must have a Graphite account in order to use the merge queue. Sign up using this link. An organization admin has enabled the Graphite Merge Queue in this repository. Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue. This stack of pull requests is managed by Graphite. Learn more about stacking. |
MaheshtheDev
changed the title
|
Claude finished @MaheshtheDev's task in 1m 30s —— View job Reviewing PR #1591
Overview: Returns 503 with Issues found: None — this looks good to ship. The implementation correctly distinguishes transient failures from invalid tokens:
Score: 9/10 The only thing I'd note (not blocking): OAuth-path transient errors (e.g., JWKS timeout) aren't explicitly tested, but the implementation is shared so it would work identically. Could add a test for completeness in a follow-up. |
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
There was a problem hiding this comment.
Overview: Returns 503 with Retry-After when auth backend is unavailable instead of invalid_token, preventing clients from discarding valid credentials during transient outages.
Issues found: None — this looks good to ship.
The implementation is clean:
TransientAuthErrorproperly distinguishes backend outages (5xx, timeouts, JWKS failures) from genuinely invalid tokens (401, 403, bad signatures, expired JWTs)- The
resolveAuthUserdiscriminated union keeps the control flow explicit and type-safe - Tests cover the API key path for both 500 responses and timeouts
Score: 9/10
Minor note: OAuth transient errors (e.g., JWKS timeout) aren't explicitly tested, but the implementation logic is correct — JWKSTimeout is in TRANSIENT_ERROR_NAMES and would follow the same path.
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 2c2bbb731d
ℹ️ 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".
jose reports a non-200 JWKS response as a plain JOSEError with no status, and an unreachable host rejects with TypeError, so neither matched the name set and both still collapsed to invalid_token. Also expose Retry-After through CORS so browser clients can read it. Both raised in review on #1591.
Merge activity
|
…#1591) Cherry-picks #1587 from @Sravanjangam, plus the OAuth half on top. When the auth backend is slow or returns a 5xx, the MCP server currently answers `invalid_token`. That is the protocol's signal to discard the credential and re-authenticate, so a brief upstream blip logs every connected client out, and `sm_` API key users have no automatic way back. These requests now return 503 with `Retry-After: 5` so clients retry instead. His change covered the API key path only. This shares one `transientAuthErrorFor` helper between `validateApiKey` and `validateOAuthToken`, so a JWKS timeout or a 5xx also returns 503 on the OAuth path that Claude, Cursor and browser clients use. Genuinely bad tokens are unaffected: bad signature, expired, and no-matching-key still resolve to 401. Verified across all seven cases. Co-Authored-By: Sravanjangam <163002695+Sravanjangam@users.noreply.github.com>
a316f3a to
6cae175
Compare
2 participants
Cherry-picks #1587 from @Sravanjangam, plus the OAuth half on top.
When the auth backend is slow or returns a 5xx, the MCP server currently answers
invalid_token. That is the protocol's signal to discard the credential and re-authenticate, so a brief upstream blip logs every connected client out, andsm_API key users have no automatic way back. These requests now return 503 withRetry-After: 5so clients retry instead.His change covered the API key path only. This shares one
transientAuthErrorForhelper betweenvalidateApiKeyandvalidateOAuthToken, so a JWKS timeout or a 5xx also returns 503 on the OAuth path that Claude, Cursor and browser clients use.Genuinely bad tokens are unaffected: bad signature, expired, and no-matching-key still resolve to 401. Verified across all seven cases.
Co-Authored-By: Sravanjangam 163002695+Sravanjangam@users.noreply.github.com