Fix MCP OAuth servers hanging on tool calls after session expiry#513
Open
rschmukler wants to merge 1 commit into
Open
Fix MCP OAuth servers hanging on tool calls after session expiry#513rschmukler wants to merge 1 commit into
rschmukler wants to merge 1 commit into
Conversation
When an MCP server's OAuth session expired or was revoked server-side (e.g. Linear), tool calls would hang for the full 120s timeout and never recover, instead of detecting the broken session and re-authenticating. Root cause was in the Streamable HTTP transport: when the server returned a non-200 (401/403/404/5xx) whose body was not already a valid JSON-RPC message, plumcp synthesized a JSON-RPC error with no :id. Because the client correlates responses to pending requests by :id, that error was routed to the notification handler (and dropped), so the in-flight tool call's :on-error never fired and the call blocked until timeout — even though the HTTP status was known immediately. Fixes: - Bump plumcp to 0.2.2, which stamps the originating request's :id onto synthesized HTTP errors. The error now reaches the pending call's :on-error promptly with :plumcp.core/http-status, so the existing reinit-worthy-http-status? path flags the server for re-initialization (token refresh, or browser re-auth when the refresh token is also dead) instead of hanging. - Proactively refresh a locally-expired OAuth token before issuing a tool call, so a known-expired token skips the doomed request and full reinit entirely.
rschmukler
force-pushed
the
rs/mcp-oauth-fix
branch
from
ddc1b16 to
186ff22
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When an MCP server's OAuth session expired or was revoked server-side (e.g. Linear), tool calls would hang for the full 120s timeout and never recover, instead of detecting the broken session and re-authenticating.
Root cause was in the Streamable HTTP transport: when the server returned a non-200 (401/403/404/5xx) whose body was not already a valid JSON-RPC message, plumcp synthesized a JSON-RPC error with no :id. Because the client correlates responses to pending requests by :id, that error was routed to the notification handler (and dropped), so the in-flight tool call's :on-error never fired and the call blocked until timeout — even though the HTTP status was known immediately.
Fixes:
Bump plumcp to 0.2.2, which stamps the originating request's :id onto synthesized HTTP errors. The error now reaches the pending call's :on-error promptly with :plumcp.core/http-status, so the existing reinit-worthy-http-status? path flags the server for re-initialization (token refresh, or browser re-auth when the refresh token is also dead) instead of hanging.
Proactively refresh a locally-expired OAuth token before issuing a tool call, so a known-expired token skips the doomed request and full reinit entirely.
I added a entry in changelog under unreleased section.
This is not an AI slop.