streamable-http server: stateful session workers ignore config.cancellation_token and stay alive until keep_alive after shutdown

已关闭
#1,426 1 条评论 0 个 reaction 已指派 1 人 在 GitHub 查看

维护者通常 3 天内回复

@jamadeo 已经在做这个了。

开始于 2026年11月3日。

  • #1427 来自 @xixi-box —— 未关闭

评估

这个 Issue 还没有评估数据。

描述

bug P2 ready for work T-transport

We run one StreamableHttpService per agent run: rmcp 3.7.0 with server and transport-streamable-http-server, LocalSessionManager::default(), and the default config plus with_cancellation_token(...). It sits behind axum::serve(...).with_graceful_shutdown(...). The client is a child process. When the run ends we kill it, cancel the token and wait for the server task. The client never sends DELETE.

The stateful session created by its initialize keeps running after that. In one trace the last tools/call response went out at 00:16:43.820 and our handler was dropped at 00:21:43.823. That is SessionConfig::DEFAULT_KEEP_ALIVE (300 s) after the last event the session worker handled. The worker task owns the handler, so whatever the handler holds lives that long too. For us that kept a per-run resource alive and held up teardown for five minutes.

Reading the code (the same paths are still on main):

  • StreamableHttpService::spawn_session_worker in tower.rs is a plain tokio::spawn. Its serve_server call creates its own CancellationToken. LocalSessionManager::create_session uses WorkerTransport::spawn(worker), which also starts from a fresh token. As far as I can tell, config.cancellation_token only reaches the SSE response streams and the stateless path.
  • The worker task keeps an Arc of the session manager, and the manager keeps the LocalSessionHandle and its event_tx. So dropping the service or router doesn't close the worker's event_rx either. Only DELETE, close_session or the idle timeout end the session.

The doc comment on StreamableHttpServerConfig::cancellation_token says cancelling it terminates all active sessions, so either the docs or the behaviour is off.

Is the token meant to end stateful sessions as well? If so, passing a child of config.cancellation_token into the worker looks like it would fix this, either through WorkerTransport::spawn_with_ct in create_session or by racing it in spawn_session_worker. A way to close every session from the service or the manager on shutdown would work for us too.

For now we keep the Arc<LocalSessionManager>, call close_session for every entry in sessions once the server task has finished, and keep run-scoped state out of the handler.

Possibly related: #1325 (in-flight calls are not cancelled on disconnect in the session-manager path) and #857.

主要语言
Rust
星标
4.1k
派生
694
平均合并
4 天 16 小时
30 天内合并 PR
43

环境准备

在 Codespaces 中打开

在浏览器里用你自己的 GitHub 账号启动这个项目的开发容器。

  • 没有 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 阅读贡献指南

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

modelcontextprotocol/rust-sdk 的其他 Issue

查看 modelcontextprotocol/rust-sdk 的全部 Issue

相似的 Issue

更多 Rust Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。