fix(mcp): reconnect Streamable HTTP after MCP server restart - #12270
fix(mcp): reconnect Streamable HTTP after MCP server restart#12270schuellerf wants to merge 3 commits into
Conversation
…without bogus SSE fallback When the remote MCP process restarts, Langflow kept a stale ClientSession: tool list updates could fail with "Session terminated", the session health check could re-raise instead of discarding the session, and any Streamable HTTP failure triggered SSE fallback and could lock transport preference to SSE—masking the real issue and producing misleading TaskGroup/dual-transport errors. Invalidate all sessions for the server URL on list_tools failure, treat any health-check failure as a dead session, retry transient Streamable HTTP errors before considering SSE, only fall back to SSE for clear transport-mismatch signals (e.g. 404/405/406), reset and re-record transport preference accordingly, and bust sessions on run_tool using the same termination/connection signals. Add unit tests with mocked streamablehttp_client and sse_client.
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
This PR is too late for 1.9.0, I guess, but will be part of 1.10.0 (see #12777 ) |
…without bogus SSE fallback
When the remote MCP process restarts, Langflow kept a stale ClientSession: tool list updates could fail with "Session terminated", the session health check could re-raise instead of discarding the session, and any Streamable HTTP failure triggered SSE fallback and could lock transport preference to SSE—masking the real issue and producing misleading TaskGroup/dual-transport errors.
This invalidates all sessions for the server URL on list_tools failure, treat any health-check failure as a dead session, retry transient Streamable HTTP errors before considering SSE, only fall back to SSE for clear transport-mismatch signals (e.g. 404/405/406), reset and re-record transport preference accordingly, and bust sessions on run_tool using the same termination/connection signals.
Add unit tests with mocked streamablehttp_client and sse_client.
Please check if this makes sense and if we should do those retries…