Streamable HTTP client stays closed after an interrupted response and raises ExceptionGroup on cleanup

未关闭
#3,522 1 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

评估

难度
3/5
预计耗时
1-2 天
新手友好度
72/100
Issue 类型
缺陷
描述清晰度
描述清楚
活跃度
活跃
技术栈
python
领域
api

调研方向

从 mcp.client.streamable_http 中的 streamable_http_client 入口点开始,并针对 mcp-failure-lab 运行提供的 repro.py。跟踪中断的断开连接响应如何影响客户端和任务组清理;当断开连接失败得到报告、同一客户端上的后续 ping 成功,并且退出上下文时不会引发 ExceptionGroup 时,即表示完成。

由索引模型根据 Issue 内容生成。

描述

v1 v2
Description

With the current 2.x release, one interrupted Streamable HTTP tool response permanently closes the Python client session. The failing request is reported, but a subsequent normal request on the same client fails with MCPError: Connection closed. Exiting streamable_http_client(...) then raises an unhandled ExceptionGroup from its background task group.

The same MCP server remains healthy. Under the identical sequence, @modelcontextprotocol/sdk@1.30.0 reports the interrupted request and successfully completes the next ping on the same client.

Expected behavior

The interrupted request should fail, while a subsequent request should be able to use a fresh HTTP connection and succeed. Transport cleanup should not raise an additional ExceptionGroup.

Actual behavior
  1. disconnect interrupts its active HTTP response.
  2. Python reports the request failure.
  3. A following ping fails immediately with MCPError: Connection closed.
  4. Context cleanup raises ExceptionGroup: unhandled errors in a TaskGroup whose nested cause is httpx2.RemoteProtocolError: Server disconnected without sending a response.
Comparison

The official TypeScript client 1.30.0 receives TypeError: fetch failed for the deliberately interrupted request, then successfully sends ping through the same client. This suggests the server remains available and the problem is in Python client recovery/cleanup.

I also searched the existing issues. #3494 concerns a server-side incomplete SSE body during initialize, and #3441 concerns an unresolved 1.x request; neither appears to cover this v2 same-client recovery failure.

Minimal reproduction
# Terminal 1
npx mcp-failure-lab@0.9.0 serve --transport http --host 127.0.0.1 --port 43118 --path /mcp

# Terminal 2: save as repro.py, then run: python repro.py
import anyio
from mcp import ClientSession
from mcp.client.streamable_http import streamable_http_client

URL = "http://127.0.0.1:43118/mcp"

async def main():
    try:
        async with streamable_http_client(URL) as streams:
            async with ClientSession(
                streams[0], streams[1], read_timeout_seconds=1.0
            ) as session:
                await session.initialize()
                try:
                    await session.call_tool(
                        "disconnect", {}, read_timeout_seconds=0.6
                    )
                except BaseException as error:
                    print("disconnect:", type(error).__name__, error)

                # Expected: succeeds. Actual: MCPError: Connection closed
                print("ping:", await session.call_tool("ping", {}))
    except BaseException as error:
        # Actual: ExceptionGroup from streamable_http_client cleanup
        print("cleanup:", type(error).__name__, error)

anyio.run(main)
Environment

Python 3.12.14; mcp 2.2.0; macOS arm64. Server: mcp-failure-lab 0.9.0; protocol 2026-07-28.

主要语言
Python
星标
24.3k
派生
4k
平均合并
1 天 1 小时
30 天内合并 PR
31

贡献指南

打开贡献指南

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

modelcontextprotocol/python-sdk 的其他 Issue

查看 modelcontextprotocol/python-sdk 的全部 Issue

相似的 Issue

更多 Python Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。