2.3 KiB
2.3 KiB
需求：R-023 MCP 状态灯自适应探测（MCP 服务恢复后自动回绿）· 讨论中
登记：2026-09-09 ｜ 来源：老师反馈（R-022 之后实测 MCP 灯同样不自动恢复）｜ 状态：讨论中（AI 提议定稿，待老师确认） 归属：迭代 19-指示灯状态自适应探测 ｜ 实现状态：已实现（待验收）
症状（老师反馈，2026-09-09）
QMT 健康灯修复后复查发现：会话头部 MCP 指示灯也存在同样的「状态不自动恢复」—— MCP 服务（QMT Bridge /mcp）启动/恢复后，MCP 灯停留在上次失败态，不会自动回绿。
根因
QmtMcpManager 的状态缓存只在 挂载 / 配置切换 / 手动探测（点击「检测 MCP」）时刷新，无任何定时回路； sync-status 端点每 10s 读的只是这份缓存。dsh-mcp-client 自带的 reconnect 只恢复真实连接 （fiber 层），并不刷新插件自己的状态缓存——所以「连接恢复了、灯还是红的」。
方案（AI 提议，与 R-022 同模式，owner = QmtMcpManager）
结果驱动自适应探测（对齐 QmtHealthMonitor）：
- connected → 每 5 分钟探测一次（稳态，低开销）；
- 非 connected（error/异常）→ 每 10 秒快速重试——MCP 服务恢复后灯 ≤20s 自动回绿；
- 无激活连接（url 为空）不探测不调度；dispose() 后停止调度；
- 探测仍走 SDK 独立只读握手（Client connect → initialize + tools/list），与 dsh-mcp-client 自管连接互不干扰。
边界（不做）：不接管/不替代 dsh-mcp-client 的重连（那是真实连接层，保持现状 Q5）； 不新增配置项（间隔为常量，测试经构造参数注入）；前端/API 零改动（getStatus 读缓存语义不变）。
决策记录
| 项 | 结论 | 讨论 |
|---|---|---|
| 非连接态重试间隔 | 10s | 与前端 sync-status 10s 轮询、R-022 QMT 灯一致；MCP 探测最坏挂 8s 超时，快失败场景成本可忽略 |
| 已连接稳态间隔 | 5 分钟 | 与 R-022 一致；MCP 握手比重（initialize+tools/list），健康态不空转 |
| 调度停止条件 | 无激活连接 / dispose / unmount | 无 url 时探测早退置 disabled 并取消定时器，避免空转 |
| 并发防护 | _probing 去重（同 QmtHealthMonitor._inFlight） | 定时器与手动/热切换探测可能撞车 |