Clean up sessions after legacy initialize parsing fails
メンテナーはふだん 3 日以内に返信
@bolinfest がすでに取り組んでいます。
2026年10月14日 から。
評価
この issue はまだ評価されていません。
説明
Problem
A legacy Streamable HTTP initialize response can include an MCP session ID in
its response headers while its JSON or SSE payload is malformed or empty. The
client currently parses the initialize payload before its normal session
cleanup state is established. If parsing fails, the worker exits without
sending the bounded DELETE for the session that the server already created.
The same gap exists when Auto lifecycle discovery falls back to legacy
initialize.
Proposed direction
- Capture the raw session ID from a JSON or SSE initialize response before
parsing it. - Retain the headers that were actually used for that initialize request.
- If initialize parsing fails, run the existing bounded DELETE behavior before
returning the parse error. - On successful parsing and protocol negotiation, replace that provisional
cleanup state with the normal negotiated session cleanup state. - Cover both direct legacy initialization and discovery fallback.
This proposal is deliberately limited to initialize parse failures. Draft
#1267 introduces a broader run_session/outer-cancellation lifecycle and also
centralizes cleanup. The focused change would not copy that refactor, stalled
body handling, or its cancellation suite. I would be happy to fold the narrow
case into #1267 instead if that is the preferred direction.
Planned validation
Source-module transport tests would supply malformed and empty initialize SSE
streams carrying a raw session ID. Direct initialize and Auto fallback cases
would verify failure plus exactly one DELETE for that raw session.
Would maintainers prefer this focused fix as a separate PR or as a test and
delta on #1267?
- 主要言語
- Rust
- スター
- 4k
- フォーク
- 662
- 平均マージ
- 3日 19時間
- マージ済み PR（30日）
- 35
環境構築
このプロジェクトの開発コンテナを、あなたの GitHub アカウントでブラウザ上に起動します。
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートなし
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
modelcontextprotocol/rust-sdk のほかの issue
-
Streamable HTTP client: a 401 or 403 with a JSON-RPC error body and no WWW-Authenticate loses its HTTP status対応中かも @aton-of-data が 3 日前に担当しました。 オープンbug P2 ready for work T-security T-transport
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
modelcontextprotocol/rust-sdk#1339 ·
メンテナーはふだん 3 日以内に返信
-
auth: refresh_token() requests offline_access that was never granted, so refreshes fail with invalid_scope対応中かも @jstar0 が 6 日前に担当しました。 オープンbug P1 ready for work T-security T-transport
難易度 2/5 1〜3時間 初心者へのやさしさ 65/100
modelcontextprotocol/rust-sdk#1330 ·
メンテナーはふだん 3 日以内に返信
-
P3 question Stale T-documentation T-enhancement
難易度 1/5 1時間未満 初心者へのやさしさ 86/100
modelcontextprotocol/rust-sdk#1155 · コメント 1 件 ·
メンテナーはふだん 3 日以内に返信
-
Expose body-free HTTP status and Retry-After metadata対応中かも @bolinfest が今日担当しました。 オープン
modelcontextprotocol/rust-sdk#1356 · コメント 1 件 · 担当者 1 名 ·
メンテナーはふだん 3 日以内に返信
-
DCR ignores advertised token endpoint authentication methods対応中かも @bolinfest が今日担当しました。 オープンbug P2 ready for work T-security
modelcontextprotocol/rust-sdk#1355 · コメント 1 件 · 担当者 1 名 ·
メンテナーはふだん 3 日以内に返信
modelcontextprotocol/rust-sdk の issue をすべて見る
似ている issue
-
ai_p1 comp-message-queues
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
ClickHouse/ClickHouse#125890 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 66/100
storytold/photocraft#5710 ·
メンテナーはふだん 1 日以内に返信
-
Two tests fail on a Windows checkout: a CRLF parse in feature_walk_tests, an 8.3 TEMP path in libraries_tests対応中かも @CamWight が今日担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
bherbruck/solvecraft#1186 · コメント 1 件 ·
-
area: screenshot audit bug good first issue priority: P3 security severity: info type: correctness
難易度 2/5 1〜3時間 初心者へのやさしさ 70/100
pierruno-labs/prowl#31 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 70/100
limitlessprojects/Go-Hybrid#50 ·
メンテナーはふだん 1 日以内に返信