modelcontextprotocol / modelcontextprotocol/java-sdk
McpClientSession/McpServerSession: pending response entries leak when a request times out or is cancelled
还没有人认领这个 Issue。
- 主要语言
- Java
- 星标
- 3.7k
- 派生
- 1.1k
- 平均合并
- 1 天 15 小时
- 30 天内合并 PR
- 9
描述
Bug description
McpClientSession.sendRequest and McpServerSession.sendRequest put an entry into pendingResponses when a request is sent, but only remove it when a response arrives or the send itself fails. If the downstream .timeout(...) fires — or the caller cancels the Mono — no cleanup hook runs, so the entry stays in pendingResponses forever (request IDs are unique per request, so it is never overwritten).
The streamable variant already cleans up after its timeout (McpStreamableServerSession.McpStreamableServerSessionStream.sendRequest calls this.pendingResponses.remove(requestId) in a doOnError after .timeout(requestTimeout)), which suggests the legacy paths missing this is an oversight.
Amplifier
KeepAliveScheduler pings every session periodically via sendRequest(PING, ...). A dead or hung session therefore accumulates one leaked entry per ping interval on both the client and the server side; long-lived sessions grow unboundedly until close().
Suggested fix
Mirror the streamable pattern in both sendRequest methods:
.timeout(this.requestTimeout)
.doOnError(e -> this.pendingResponses.remove(requestId))
.doOnCancel(() -> this.pendingResponses.remove(requestId))
.handle(...)
Removal is idempotent, and the late-response path already tolerates a missing key.
I have the fix plus a regression test (testRequestTimeoutRemovesPendingResponse in McpClientSessionTests, asserting the map is empty after a timeout) ready and will open a PR referencing this issue.
贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
调研方向
先从 McpClientSession.sendRequest 和 McpServerSession.sendRequest 开始,然后与 McpStreamableServerSession.McpStreamableServerSessionStream.sendRequest 进行比较。运行指定的 McpClientSessionTests 回归测试,并为超时和取消路径添加等效覆盖;任一条件发生后 pendingResponses 为空即表示完成。
由索引模型根据 Issue 内容生成。
评估
- 技术栈
- java
- 领域
- api, backend, testing
- Issue 类型
- 缺陷
- 难度
- 3/5
- 预计耗时
- 1-2 天
- 活跃度
- 活跃
- 描述清晰度
- 描述清楚
- 新手友好度
- 35/100