* fix(mcp): handle 202 Accepted for Streamable HTTP notifications
The MCP Streamable HTTP spec requires servers to respond with
202 Accepted (empty body) for JSON-RPC notifications like
`notifications/initialized`. The HTTP transport tried to parse
this empty body as JSON, which failed and broke the session
handshake — subsequent requests like `tools/list` were rejected
because the server considered the session uninitialized.
Add an early return for 202 responses that produces an empty
McpResponse without attempting body parsing.
Fixes#1436
Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>
* fix(mcp): wire session manager into transport for non-OAuth HTTP clients
The factory used McpClient::new_with_config().with_session_manager()
which only set the session manager on the client, not on the
HttpMcpTransport. The transport never captured Mcp-Session-Id from
responses, so subsequent requests lacked the header and the server
rejected them as uninitialized.
Fix by constructing the HttpMcpTransport with the session manager
before wrapping it in Arc, matching the pattern already used by
new_authenticated().
Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>
* refactor(mcp): deduplicate factory HTTP path, gate dead-code methods as test-only
- Collapse the two identical non-OAuth HTTP branches in
`create_client_from_config()` into one (early-return for the
authenticated path, fall through for the common case).
- Gate `McpClient::new_with_config()` and `McpClient::with_session_manager()`
as `#[cfg(test)]` — the factory was their only production caller and no
longer uses them. Both methods silently skip wiring the session manager
into the transport, which was the root cause of #1436.
- Add doc warnings on both methods explaining the footgun.
Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>
---------
Co-authored-by: Claude Opus 4.6 (1M context) <[email protected]>
Co-authored-by: [email protected] <[email protected]>
