modelcontextprotocol / modelcontextprotocol/python-sdk

Invalid JSON-RPC envelope errors are not correlated with the original request id

オープン
#2,848 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

bug needs confirmation P2
主要言語
Python
スター
24.3k
フォーク
4k
平均マージ
1日 1時間
マージ済み PR(30日)
31

説明

Initial Checks
Description

After a normal initialization flow, several id-bearing JSON-RPC messages that are syntactically valid JSON but invalid JSON-RPC request envelopes are not correlated back to the original request id.

This is not meant to require implementations to recover an id after every low-level parse/deserialization failure. The narrower concern is that these payloads are parsed far enough to produce request-specific validation errors, while the original top-level id is still present in the payload. Preserving that id where feasible would make the error response easier for clients to correlate.

The tested inputs were:

Case Request Validation detail
wrong jsonrpc version {"jsonrpc":"1.0","id":3,"method":"ping","params":{}} JSONRPCRequest.jsonrpc: value should be "2.0"
missing jsonrpc field {"id":4,"method":"ping","params":{}} JSONRPCRequest.jsonrpc: field required
method as number {"jsonrpc":"2.0","id":8,"method":12345,"params":{}} JSONRPCRequest.method: input should be a valid string

For all three envelope-invalid inputs, I would expect -32600 Invalid Request or -32602 error response that can be correlated to the original request where possible.

Observed behavior was consistent by transport:

  • stdio: The server emits a notifications/message log notification with level:"error" and data:"Internal Server Error", but no JSON-RPC error response is sent for the original request id. A follow-up ping succeeds.
  • Streamable HTTP: The server returns HTTP 400 with a JSON-RPC error response using id:"server-error" and code:-32602, rather than the original request id. A follow-up ping succeeds over SSE.
Example Code
"""
With a Python SDK MCP server running over stdio or Streamable HTTP,
complete a normal initialization flow, then send these requests in isolation.
"""

requests = [
    # Wrong JSON-RPC version: valid JSON, invalid JSON-RPC envelope.
    {"jsonrpc": "1.0", "id": 3, "method": "ping", "params": {}},

    # Missing jsonrpc field: valid JSON, invalid JSON-RPC envelope.
    {"id": 4, "method": "ping", "params": {}},

    # method is not a string: valid JSON, invalid JSON-RPC envelope.
    {"jsonrpc": "2.0", "id": 8, "method": 12345, "params": {}},
]
Python & MCP Python SDK
* Python: `3.12.3`
* MCP Python SDK stable release: `v1.27.2` (`62137874ff26dd74d2fea80ff528a7fd9ca7a5e7`)
* Transports: stdio and Streamable HTTP

コントリビューションガイド

コントリビューションガイドを開く

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

調査の方向性

まず、3つの無効な JSON-RPC envelope payload を stdio と Streamable HTTP の両方のトランスポートに対して再現します。それらの検証およびエラーレスポンスの経路を追跡します。完了の条件は、envelope が無効なリクエストが適切な JSON-RPC エラーを返し、可能な場合は元の id を保持し、後続の ping リクエストにリグレッションを起こさないことです。

索引モデルが issue の本文から書いたものです。

評価

技術スタック
python
領域
api
issue の種類
バグ
難易度
4/5
見積もり時間
3〜5日
活発さ
活発
明瞭さ
おおむね明確
初心者へのやさしさ
48/100

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。