37 lines
2.3 KiB
Markdown
37 lines
2.3 KiB
Markdown
# 需求：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） | 定时器与手动/热切换探测可能撞车 |
|