modelcontextprotocol / modelcontextprotocol/python-sdk

In-process callback failures break tool calls and notification sends

未關閉
#3,434 1 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視

還沒有人認領這個 Issue。

v2
主要語言
Python
星號
24.3k
分支
4k
平均合併
1 天 1 小時
30 天內合併 PR
31

描述

Initial Checks

  • I confirm that I am using the newest release of the 2.x line.
  • I confirm that I searched the issue tracker before opening this issue.

Release line

2.x (current stable)

Description

Client(server) uses DirectDispatcher. If a progress callback raises, that exception crosses back into server tool execution, so a tool that otherwise returns successfully fails with UnexpectedToolError. DirectDispatcher also lets an inbound notification handler exception escape back to the sender's notify() call.

The stream-backed JSONRPCDispatcher logs and contains both callback failures. I expected the in-process path to keep the same boundary: log the callback failure, but let the protocol operation continue.

I have a small patch and regression tests for both paths and would like to fix this if maintainers want an outside pull request.

I used GitHub Copilot CLI to inspect the dispatcher paths, write the patch, and draft this report. I verified the reproduction and tests.

Example Code

import anyio

from mcp import Client
from mcp.server.mcpserver import Context, MCPServer

server = MCPServer("callback-repro")


@server.tool()
async def work(context: Context) -> str:
    await context.report_progress(1, 1)
    return "done"


async def broken_progress(progress: float, total: float | None, message: str | None) -> None:
    raise RuntimeError("consumer failed")


async def main() -> None:
    async with Client(server, mode="2026-07-28") as client:
        result = await client.call_tool("work", progress_callback=broken_progress)
        print(result.content[0].text)


anyio.run(main)

Current main ends with:

UnexpectedToolError: Error executing tool work

The tool should print done. The callback failure should still be logged.

Verification

With only the regression tests applied to clean main:

uv run --frozen pytest tests/shared/test_dispatcher.py \
  -k 'progress_callback_exception_does_not_fail_request or notification_handler_exception_does_not_reach_sender' -q
# 2 failed, 2 passed. Both DirectDispatcher cases failed.

With the two callback guards applied:

uv run --frozen pytest tests/shared/test_dispatcher.py \
  -k 'progress_callback_exception_does_not_fail_request or notification_handler_exception_does_not_reach_sender' -q
# 4 passed

Python & MCP Python SDK

Python 3.12.13
mcp 2.1.1
mcp 2.1.2.dev4+d060b36e at d060b36e1d095ef6e93e07ba5d59bb69b2ad449a
macOS

貢獻指南

開啟貢獻指南

從這裡開始

  1. 先讀完整個 Issue,再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫,在一個分支上完成修改。
  4. 送出 Pull Request,並在描述裡引用這個 Issue 編號。

研究方向

從 DirectDispatcher 路徑著手,將其回呼失敗處理與串流支援的 JSONRPCDispatcher 進行比較。使用提到的兩個 -k 案例執行 tests/shared/test_dispatcher.py,以重現這些失敗。完成的標準是兩個 DirectDispatcher 案例都通過,成功的工具呼叫和通知傳送持續正常運作,且回呼失敗會被記錄。

由索引模型根據 Issue 內容生成。

評估

技術堆疊
python
領域
backend-api-design
Issue 類型
缺陷
難度
3/5
預估耗時
1-2 天
活躍度
活躍
描述清晰度
描述清楚
新手友好度
84/100

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。