Client never answers a server `ping` sent during the `initialize` handshake
维护者通常 2 天内回复
评估
这个 Issue 还没有评估数据。
描述
Describe the bug
This is about the 2025-11-25 initialize handshake. While the client waits for the initialize response, expect_response in service/client.rs drops any ping from the server:
// Server could send pings before handshake
ServerJsonRpcMessage::Request(ref request)
if matches!(request.request, ServerRequest::PingRequest(_)) =>
{
tracing::trace!("Received ping request. Ignored.")
}
Nothing is written back, so the server's ping never gets a response. A server that times out its pings can treat the connection as stale and drop it. A ping sent after notifications/initialized is answered normally.
The server side already does this. #745 made the server answer a client ping that arrives before initialize.
To Reproduce (main at 8d226f4)
Over a tokio::io::duplex transport, with both sides on 2025-11-25, a raw server reads initialize, writes a ping, and then writes the InitializeResult:
<- {"jsonrpc":"2.0","id":0,"method":"initialize","params":{"capabilities":{},"clientInfo":{"name":"rmcp","version":"3.5.1"},"protocolVersion":"2025-11-25"}}
-> {"jsonrpc":"2.0","id":"srv-ping-pre","method":"ping"}
-> {"jsonrpc":"2.0","id":0,"result":{"protocolVersion":"2025-11-25","capabilities":{},"serverInfo":{...}}}
After notifications/initialized arrives, it sends a second ping (srv-ping-post) for comparison. Everything the client writes back:
{"jsonrpc":"2.0","method":"notifications/initialized"}
{"jsonrpc":"2.0","id":"srv-ping-post","result":{}}
There is no response for srv-ping-pre.
Expected behavior
The client writes {"jsonrpc":"2.0","id":"srv-ping-pre","result":{}} during the handshake and then carries on waiting for the InitializeResult.
Additional context
The 2025-11-25 lifecycle lets the server send pings before it gets notifications/initialized, and the ping page says the receiver MUST respond promptly with an empty response.
expect_response is also used while waiting for server/discover. 2026-07-28 removes ping and servers there don't send requests, so I'd leave that path as it is and only answer during initialize.
I can open a PR for this.
- 主要语言
- Rust
- 星标
- 4k
- 派生
- 662
- 平均合并
- 3 天 11 小时
- 30 天内合并 PR
- 36
环境准备
在浏览器里用你自己的 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 于 7 天前认领。 未关闭bug P2 ready for work T-security T-transport
难度 2/5 1-3 小时 新手友好度 68/100
modelcontextprotocol/rust-sdk#1339 ·
维护者通常 2 天内回复
-
auth: refresh_token() requests offline_access that was never granted, so refreshes fail with invalid_scope可能已有人在做 @jstar0 于 9 天前认领。 未关闭bug P1 ready for work T-security T-transport
难度 2/5 1-3 小时 新手友好度 65/100
modelcontextprotocol/rust-sdk#1330 ·
维护者通常 2 天内回复
-
P3 question Stale T-documentation T-enhancement
难度 1/5 1 小时以内 新手友好度 86/100
modelcontextprotocol/rust-sdk#1155 · 1 条评论 ·
维护者通常 2 天内回复
-
outputSchema is generated for the deserialize contract; tool results are serialised可能已有人在做 @connor4312 于 1 天前认领。 未关闭bug P2 ready for work T-handler
modelcontextprotocol/rust-sdk#1374 · 2 条评论 · 已指派 1 人 ·
维护者通常 2 天内回复
-
Streamable HTTP client: update the stored endpoint URI after a 308可能已有人在做 @connor4312 于 1 天前认领。 未关闭enhancement P3 T-transport
modelcontextprotocol/rust-sdk#1373 · 2 条评论 · 已指派 1 人 ·
维护者通常 2 天内回复
查看 modelcontextprotocol/rust-sdk 的全部 Issue
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 62/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 68/100
维护者通常 1 天内回复
-
难度 1/5 1 小时以内 新手友好度 82/100
521xueweihan/HelloGitHub#4023 ·
-
难度 2/5 1-3 小时 新手友好度 75/100
cloudflare/pingora#1055 ·
维护者通常 1 天内回复
-
enhancement
难度 2/5 1-3 小时 新手友好度 75/100
维护者通常 1 天内回复