[Bug] Expired MCP session causes repeated tool-call failures without reconnect or circuit breaking

[Orua]

DSH_MCP_Expired_Session_Bug_Evidence_20260820.zip
I reproduced an MCP session recovery problem in DeepSeek Harness.

After the MCP session expires, DSH continues exposing the stale tools. Every subsequent call returns:

MCP error -32001: Unknown or expired MCP session

DSH did not appear to reinitialize the MCP connection, refresh tools/list, remove the unavailable tools, or stop repeated calls with the same error.

I reproduced it in two turns:

• Turn 1: 538.83 seconds, 67 tool calls, 6 identical MCP errors
• Turn 2: 291.45 seconds, 29 tool calls, 6 identical MCP errors
• Total: 51,002 raw events and 39,110 reasoning events
• Average reasoning delta: approximately 4 characters per event

The model repeatedly replanned after the tool failures, but changing the model would not repair an expired MCP session. I believe the primary problem is DSH's MCP lifecycle handling, amplified by the lack of a repeated-error circuit breaker and very fine-grained reasoning events.

Expected behavior:

• Detect an expired MCP session and invalidate it
• Reinitialize the MCP connection and refresh tools/list
• Retry once when safe
• Disable the affected tools if reconnection fails
• Stop repeated calls after the same deterministic error occurs multiple times
• Optionally aggregate reasoning deltas before persistence and streaming

Related discussions:

• Runaway agent loop: 【BUG】harness死循环 #3228
• Excessive delta events: History payload bloat: a ~50-message page returns ~270k stream-delta events (~64 MB) #2654
• Large reasoning chunk history: Web host TTFT climbs to 50-170s under any sessions that has subagent fan-out / mature sessions - three measured contributors (host-side, not gateway) #3235

Could you confirm whether -32001 Unknown or expired MCP session is currently treated as a recoverable error, and whether automatic MCP reinitialization or repeated-error circuit breaking is planned?

I have attached a sanitized evidence package containing timestamps, metrics, reproduction steps, event counts, and reasoning-delta samples. It excludes credentials and private business data.

[denial123789]

I traced this against rc.8 (141eb6f). The failure sits between the MCP tool executor and the connection supervisor:

• reconnection starts when connection establishment fails or the SDK transport fires onclose;
• an application-level tools/call failure such as -32001 is surfaced as an ordinary tool error;
• that error does not invalidate the current connection generation or rerun initialize + tools/list, so the stale tools remain visible and the model can replan against them.

For current operators, I would contain it in this order: cancel the active turn, stop follow-up prompts, reload or disable the exact MCP client row/Host, require a successful new initialization and complete tool discovery, then make one proof call from a fresh Agent Session. Retry automatically only for read-only or proven-idempotent work; verify unknown writes before replay.

For the runtime, a useful repair contract is: classify session-invalid errors, atomically invalidate only that generation, collapse concurrent failures into one reconnect, stop new admission, rediscover tools, and open a circuit if the recovered generation returns the same fingerprint. Reasoning-delta aggregation may reduce event volume, but it is separate from MCP lifecycle correctness.

I wrote the full source-backed runbook, including stdio/HTTP recovery branches, retry safety, and acceptance gates:
https://sandbaseai.github.io/deepseek-harness-handbook/expired-mcp-session-loop.html

[Orua]

Thanks for tracing this against rc.8. Your explanation matches the failure pattern I observed, especially the gap between tool-call errors and generation invalidation/reinitialization.

[Jstn-1g]

Thanks @denial123789 for the trace and recovery analysis. I reproduced #3489 as an expired stateful Streamable HTTP session and published a scoped reference implementation as one commit against current master b150a55:

• Branch: https://github.com/Jstn-1g/deepseek-harness/tree/reference/discussion-3489-expired-mcp-session
• Exact commit: Jstn-1g@1081617

The patch retires only protocol-proven session loss: HTTP 404 while the exact SDK transport still owns the MCP session ID, plus the exact reported legacy McpError(-32001, "Unknown or expired MCP session") fingerprint. It withdraws stale tool definitions synchronously, fences concurrent and late generations, closes the old client, then reuses the existing bounded fresh-Initialize and complete-discovery path. The failed tool call is surfaced unchanged and is never replayed automatically. Stateless 404s, ordinary timeouts, authentication/server failures, result-level MCP errors, and stdio behavior remain unchanged.

Verification on that exact commit:

• 113 focused MCP unit/race tests; 100% statement, branch, function, and line coverage for the two affected source files
• 23 real-transport E2E tests, including expiry through the SDK StreamableHTTPServerTransport
• keyless assembled Loader/ACP snapshot proving the MCP tool is advertised before failure, the exact error is preserved without replay, and the next model request plus logged request header omit the stale tool
• typecheck, lint, workspace constraints, and all 28 documentation gates pass

This is intended as a cherry-pickable reference implementation; it does not claim upstream adoption.

[weijiafu14]

MCP 生命周期那一半，@denial123789 的溯源和 @Jstn-1g 的参考实现已经把话说尽了，我没有增量。我想说的是被这两份工作显式排除在外的那另一半——你提的"重复错误熔断"。

@denial123789 写了 "Reasoning-delta aggregation may reduce event volume, but it is separate from MCP lifecycle correctness"，@Jstn-1g 的补丁也明确 scope 掉了重放与熔断。两位都是对的：那确实是独立的一件事。但它不是次要的一件事——你的数据里，67 次工具调用只有 6 次是那个错误，剩下 61 次是模型在错误反馈下的重新规划。生命周期缺陷造成 6 次失败，缺少刹车造成了另外那 500 多秒。

这个形状我这两天在社区里见到第四次了

帖	工具层给了什么反馈	模型的反应
#3568	参数解析失败 → 静默退化成空 {} → server 报"缺少必填参数"	以为自己没传参，原样重发，17 步
#2979	工具名被空 delta 覆盖 → 调用不存在的工具	自责并继续犯同样的错
#3819	同族	循环
本帖	-32001 Unknown or expired MCP session	重新规划 61 次，而这个错误无论怎么规划都不会变

共同点是同一句话：工具层返回了一个模型无法据以纠正行为的错误，而系统里没有任何东西注意到"同一个错误又来了"。

四例里的错误性质各不相同（参数格式、流式重组、会话过期），但失败模式完全一样，这说明缺的不是针对某一类错误的修复，而是一个通用的观察：确定性错误重复出现时，重试不会有不同结果。

为什么值得单独提

熔断被反复归类为"优化项"，我觉得这是低估了。它有一个别的修法都没有的性质：它不需要知道错误是什么意思。

• 修 MCP 生命周期，需要认识 -32001 这个指纹（@Jstn-1g 的补丁正是这么做的，也只能这么做）；
• 修参数解析，需要理解 JSON 累加器；
• 而熔断只需要看"错误指纹是否重复" —— 它对上面四种根因一视同仁，也对还没有人发现的第五种一视同仁。

换句话说：每修一个具体根因，只挡住一类循环；加一次熔断，挡住所有还没被发现的循环。 对一个正在快速迭代的运行时来说，后者的边际价值只会越来越高。

@denial123789 的修复契约里其实已经有它了——"open a circuit if the recovered generation returns the same fingerprint"。我想说的是这一句值得从 MCP 的上下文里抽出来放到工具执行层：不管这个工具是 MCP 的、原生的还是插件注册的，同一个 (工具, 错误指纹) 在一轮里重复 N 次就该停。

如果要提成独立条目，我建议把上面四帖一起引上——一个失败模式有四份独立复现，比任何单帖都更能说明它是结构性的。

我不推荐你换 MCP 运行时，理由要说清楚

我维护 pi2dsh，它能跑一套 Pi 生态的 MCP 运行时，我们在真 DSH loop 上端到端验过 stdio / Streamable HTTP / SSE 和重连。按理说这里该推销一下。但我不推荐，因为 @denial123789 划的那条线正好是我没有证据的那条线：

reconnection starts when connection establishment fails or the SDK transport fires onclose; an application-level tools/call failure such as -32001 is surfaced as an ordinary tool error

我们验过的"重连"是传输层断开触发的那种。"应用层 tools/call 返回 -32001 时会不会判定会话失效并重建"——这个具体分支我一次没测过。 而这恰恰是你这条 bug 的全部要害。绝大多数 MCP 客户端实现在这里的默认行为是一样的（把 JSON-RPC error 当普通工具错误往上抛），所以我更倾向于认为我们有同一个缺口，只是没人去撞过。

没测过就不能说绕得开。你换过去很可能只是换成另一套同样不认 -32001 的实现，白折腾一遍。

我们也不修 DSH 自家组件——dsh-mcp-client 的生命周期、agent loop 的熔断都在 DSH 里，上面全是分析和跨帖串联。

（另：你那份证据包的质量——两轮的调用数/错误数/事件数/reasoning delta 平均长度全都量化了——是我在这个社区见过最好的之一。上面那张四帖对照表能成立，正是因为你把"6 次错误 vs 67 次调用"这个比例摆了出来；换成"MCP 一直报错"就什么都推不出来了。）