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 小时
- 30 天内合并 PR
- 35
环境准备
在浏览器里用你自己的 GitHub 账号启动这个项目的开发容器。
- 没有 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 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
-
Custom hosts written as trailing-dot FQDNs (`host.local.`) aren't detected as local backends可能已有人在做 @roboomp 今天认领。 未关闭bug prio:p2 providers triaged
难度 2/5 1-3 小时 新手友好度 82/100
can1357/oh-my-pi#15798 · 3 条评论 ·
维护者通常 1 天内回复
-
requires-triage
难度 2/5 1-3 小时 新手友好度 68/100
apache/datafusion-comet#7001 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 62/100
-
builtin-port enhancement
难度 2/5 1-3 小时 新手友好度 62/100
cmlarsen/writemorebetter#235 ·
维护者通常 1 天内回复
-
Add a Storybook section to CONTRIBUTING.md可能已有人在做 @ChanakyaG2004 今天认领。 未关闭documentation good first issue
难度 2/5 1-3 小时 新手友好度 82/100
FlowwStar/FlowStar#995 · 2 条评论 ·
维护者通常 1 天内回复