38 lines
2.6 KiB
Markdown
38 lines
2.6 KiB
Markdown
# 需求：R-022 QMT 连接健康灯自适应探测（Bridge 启动/恢复后快速回绿）· 讨论中
|
||
|
||
> 登记：2026-09-09 ｜ 来源：老师反馈（会话头部 QMT 指示灯）｜ 状态：**讨论中（AI 提议定稿，待老师确认）**
|
||
> 归属：迭代 19-指示灯状态自适应探测（R-022：QMT 健康灯）｜ 实现状态：已实现（待验收）
|
||
|
||
## 症状（老师反馈，2026-09-09）
|
||
|
||
启动 QMT Bridge 后，会话头部四个指示灯中「持仓数据 / 行情数据 / MCP」几秒内自动点亮，
|
||
唯独「QMT连接」灯一直不亮（停留在红/灰态）——「QMT 连接状态自动检查好像没有生效」。
|
||
|
||
## 根因
|
||
|
||
QmtHealthMonitor 只在**插件启动时 + 每 5 分钟**探测一次激活 Bridge /health（2026-09-01 迭代 04 定的
|
||
「服务端 5 分钟定时探测 + 缓存」机制），结果缓存内存；前端 10s 轮询 sync-status 只读缓存、不触发探测。
|
||
其余三灯靠高频自愈回路：PositionSync 10s / QuoteSync 5s 定时拉 Bridge、MCP 客户端自带失败重连，
|
||
Bridge 恢复后秒级回绿。唯独健康缓存要等满 5 分钟下一次探测——Bridge 在两次探测间启动/恢复时，
|
||
灯长期停留在上一次失败结果，观感即「自动检查没生效」（反向同理：Bridge 中途宕机，灯最多 5 分钟不转红）。
|
||
|
||
## 方案（AI 提议，老师拍板确认）
|
||
|
||
**自适应探测节奏（owner = QmtHealthMonitor，单点改动）**：
|
||
|
||
- 健康 → 每 5 分钟探测一次（**稳态，维持原设计低开销**）；
|
||
- 异常/未知（含从未探测成功）→ **每 10 秒快速重试**（与前端 sync-status 10s 轮询对齐，
|
||
与持仓/行情 5-10s 恢复节奏一致）——Bridge 启动后灯 ≤20s 自动回绿。
|
||
|
||
**边界（不做）**：前端读缓存秒回不变；API/前端零改动；健康稳态间隔不放宽不放窄（5 分钟不变）；
|
||
不新增配置项（间隔为常量，测试经构造参数注入）；不做 read-path 触发探测（定时器已覆盖，避免耦合）。
|
||
|
||
## 决策记录
|
||
|
||
| 项 | 结论 | 讨论 |
|
||
|---|---|---|
|
||
| 异常重试间隔 | 10s | 与前端 10s 轮询对齐；5s 会翻倍失败探测开销（每次失败探测最长挂 5s 超时） |
|
||
| 健康稳态间隔 | 5 分钟维持 | 原设计为省探测开销；异常态才快速重试，健康态不空转 |
|
||
| 防并发/调度 | setTimeout 链 + _inFlight 去重 | 沿用原防并发语义；手动探测/热切换共用同一节奏重排 |
|
||
| baseUrl 解析异常 | 落 healthy:false 缓存走快速重试 | 原实现解析在 try 外，异常会丢缓存导致灯灰且不重试 |
|