modelcontextprotocol / modelcontextprotocol/python-sdk

client's `read_stream_writer` open after SSE disconnection hanging `.receive()`

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

还没有人认领这个 Issue。

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

描述

Initial Checks
Description

This issue MAY be related to the following

Experiencing deadlocks on streamable_http transport. In order to reproduce the issue the following can be run.

import asyncio
import logging
import threading
import time

from fastmcp import Client, FastMCP
from fastmcp.client.transports import StreamableHttpTransport

logging.basicConfig(
    level=logging.DEBUG,
    format="%(asctime)s - %(name)s - %(levelname)s - %(message)s",
    handlers=[logging.StreamHandler()],
)

logger = logging.getLogger(__name__)

HOST = "127.0.0.1"
PORT = 8765
SERVER_URL = f"http://{HOST}:{PORT}/mcp"

mcp = FastMCP(name="timeout issue")

SSE_TIMEOUT = 0.1
SLEEP = 60


@mcp.tool
def blocking_call() -> str:
    time.sleep(SLEEP)
    return "42"


def run_server():
    mcp.run(transport="streamable-http", host=HOST, port=PORT)


async def test_blocking_sse():
    transport = StreamableHttpTransport(SERVER_URL, sse_read_timeout=SSE_TIMEOUT)
    async with Client(transport) as client:
        tools = await client.list_tools()
        print(f"available tools: {[t.name for t in tools]}")
        result = await client.call_tool("blocking_call", {})
        print(f"blocking result: {result}")


if __name__ == "__main__":
    server_thread = threading.Thread(target=run_server, daemon=True)
    server_thread.start()

    time.sleep(2)

    try:
        asyncio.run(test_blocking_sse())
    finally:
        logger.info(f"{time.strftime('%Y-%m-%d %H:%M:%S')} [CLIENT] Shutting down...")

Execution context := locally built fastmcp at this commit 790ea92

Observed Behavior: the client hangs forever after the SSE read timeout fires, looking at the logs:

  • tool request is sent, server returns HTTP 200 with [Content-Type: text/event-stream]
  • server starts executing the tool (blocking time.sleep(60))
  • client's SSE read timeout fires (after ~5 seconds with default httpx timeout)
  • client closes the HTTP connection
  • client hangs indefinitely - call_tool() never returns
  • the tool eventually completes on the server side, but when the server tries to send the response back, it gets BrokenResourceError because the HTTP connection was already closed by the client.

I know noting about nothing, so I can imagine the above example is just an issue on my side, maybe:

  • sse timeout should always be greater or equal to the expected timeout of tool calls (now that sse_read_timeout is deprecated it's httpx.Timeout counterpart should be >= tool timeout)
  • long running tool calls MUST send progress updates

but one thing is for sure and that is, the above configuration hangs indefenitely because the session layer never gets to know that the transport layer is dead after the SSE stream is closed

Within my ignorance of many aspects of the implementation, the missing else branch seems to be the root cause.

https://github.com/modelcontextprotocol/python-sdk/blob/a9cc822a1051b1bd2b6b9b57e9e4136406983b61/src/mcp/client/streamable_http.py#L433-L435

and the fix looks something like

if last_event_id is not None:  # pragma: no branch 
    ...
else:
    error_response = JSONRPCError(...)
    await ctx.read_stream_writer.send(SessionMessage(JSONRPCMessage(root=error_response)))

consequently raising McpError

Example Code

Python & MCP Python SDK
Execution context for ease of implementation 
- `mcp==1.24.0`
- example codebase run against locally built `fastmcp` at [790ea92](https://github.com/jlowin/fastmcp/tree/790ea92eb59256da68c83097321ebde8f8819bcf) --> 1.24.0
- Python: `python-3.12.7-macos-aarch64-none/bin/python3.12`

贡献指南

打开贡献指南

从这里开始

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

调研方向

从 src/mcp/client/streamable_http.py 的第 433-435 行附近开始,使用 StreamableHttpTransport 的 Python 示例复现挂起的调用。跟踪 SSE 读取超时如何关闭连接,以及 session 如何消费 read_stream_writer 消息。完成的标准是:超时的客户端调用能够返回或抛出异常,而不是无限期挂起。

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

评估

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

把新 issue 发到你的邮箱

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