modelcontextprotocol / modelcontextprotocol/python-sdk

Deep JSON-RPC request over stdio logs a validation error and leaves the original request pending

Đang mở
#2,751 1 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

bug needs confirmation P2
Ngôn ngữ chính
Python
Star
24.3k
Fork
4k
Merge trung bình
1 ngày 1 giờ
Pull request đã merge (30 ngày)
31

Mô tả

Initial Checks
Description

When the Python SDK stdio server receives an id-bearing JSON-RPC request with a deeply nested params object, the server can log a stream validation error and remain alive, but the original request is never completed with either a JSON-RPC result or a JSON-RPC error. I am filing this as a stdio response-completion/robustness issue.

In the reproduction below, a post-initialization ping request first failed receiving a response at depth 256. The server stayed responsive: follow-up shallow pings succeeded, and the process did not exit. The observable problem is that the original request id remains pending until the client-side timeout.

This also does not appear to be the same response-correlation issue where the server returns an error with id:"" or another mismatched concrete id. If the parser cannot recover the original request id, a JSON-RPC parse error with id:null would be the conventional response. MCP's typed schema models error-response id as optional string | number, so omitting the id would also be easier to reason about than leaving the request pending. On stdio, I observed an error notification and stderr validation message, but not a JSON-RPC error response frame for the original request id. From a normal JSON-RPC request/response client's perspective, the request remains incomplete.

The most relevant issue I found is #1333, but it appears to describe a different stdio responsiveness issue: slow message processing can block subsequent input. In this reproduction, the server remains responsive to later shallow pings, while the original malformed/deep request is left pending.

When processing the deeply nested stdio request, the server emitted a validation message like this:

Received exception from stream: 1 validation error for JSONRPCMessage
Invalid JSON: recursion limit exceeded

The server also emitted an MCP logging notification similar to:

{"jsonrpc":"2.0","method":"notifications/message","params":{"level":"error","logger":"mcp.server.exception_handler","data":"Internal Server Error"}}

That notification shows that the server observed the parser/validation failure, but it does not complete the pending request id.

For comparison, the Python Streamable HTTP servers did not show this pending-request behavior for the same deeply nested ping request. At depth 256 and above, both stateful and stateless HTTP returned a JSON-RPC parse error promptly, for example:

{"jsonrpc":"2.0","id":null,"error":{"code":-32700,"message":"Parse error: recursion limit exceeded ..."}}

That HTTP behavior is not what I am reporting here. I am using it only as a baseline: the stdio path leaves the request pending, while the HTTP path returns a bounded parse error.

Example Code
# Run the stdio server, complete a normal initialization phase, then send a deeply nested `ping` request like this:

import json

depth = 256
params = {"leaf": True}
for i in reversed(range(depth)):
    params = {f"p{i}": params}

print(json.dumps({
    "jsonrpc": "2.0",
    "id": 900256,
    "method": "ping",
    "params": params,
}))

'''
Expected: a JSON-RPC result or JSON-RPC error response that completes request id `900256`, or some other documented bounded failure mode.

Observed:

Depth 32:  response returned successfully.
Depth 64:  response returned successfully.
Depth 128: response returned successfully.
Depth 256: no response for the request id within 7 seconds; later shallow ping succeeded.
Depth 512+: same pending-request behavior; later shallow pings still succeeded.
'''
Python & MCP Python SDK
- Python: 3.12.3 on Ubuntu 24.04
- MCP Python SDK stable release: `v1.27.2` (`62137874ff26dd74d2fea80ff528a7fd9ca7a5e7`)
- MCP Python SDK `main` snapshot (fetched 2026-06-01): `616476f6927a5c64213ea97bbd36a7466f410775`

Hướng dẫn đóng góp

Mở hướng dẫn đóng góp

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Hướng nghiên cứu

Bắt đầu từ đường đi xác thực thông báo và xử lý lỗi của máy chủ stdio trong Python SDK, đối chiếu với hành vi parse-error của Streamable HTTP được mô tả trong báo cáo. Tái tạo payload ping lồng nhau ở độ sâu 256 và 512, sau đó xác minh rằng yêu cầu nhận được kết quả hoặc lỗi JSON-RPC có giới hạn, trong khi các ping nông hơn về sau vẫn hoạt động.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Đánh giá

Công nghệ
python
Lĩnh vực
api, backend
Loại issue
Lỗi
Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức độ hoạt động
Ít trao đổi
Độ rõ ràng
Khá rõ ràng
Mức phù hợp với người mới
47/100

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.