订单跟踪严重 Bug 分析

对当前系统订单跟踪（WebSocketOrderManager + 消息路由 + 超时/重连）进行代码分析，识别可能导致错误成交判定、永久阻塞或数据错误的严重 bug。

1. 架构与数据流概览

订单跟踪核心在 src/trading/websocket_order_manager.py（WebSocketOrderManager），与 src/trading/executor.py 的 _track_limit_order、src/services/realtime_kline_service_base.py 的 WS 回调配合工作。

sequenceDiagram
  participant Exec as Executor
  participant Mgr as WebSocketOrderManager
  participant WS as KlineService WS callback
  Exec->>Mgr: track_order(oid, coin, timeout)
  Mgr->>Mgr: _monitor_order(oid, tracking) [daemon thread]
  WS->>Mgr: handle_message(orderUpdates/userFills)
  Mgr->>Mgr: _resolve(oid) or _resolve(oid, tracking, status, px, sz)
  Mgr->>Mgr: result_event.set()
  Exec->>Mgr: wait_for_order(tracking) [block until result_event]

• 唯一解析路径：_resolve()（WS 模式只传 oid，HTTP/超时模式传 oid, tracking, status, px, sz，identity check 防误操作被替换的 tracking）。
• 消息来源：订单消息由 K 线服务 WS 回调路由到 _get_ws_order_manager().handle_message()；若 manager 未就绪则进入 _order_msg_buffer，仅在后续任意一条新消息到达时才回放缓冲。

2. 严重 / 高影响 Bug

2.1 订单消息缓冲区仅在“下一条消息”到达时回放，可能长期误判为超时（高）

位置：realtime_kline_service_base.py 约 616–654 行。

逻辑：

• 收到 orderUpdates/userFills 时若 mgr is None，消息被 append 到 _order_msg_buffer 并 return。
• 缓冲区的回放发生在每次 _on_ws_message 被调用时：先 if self._order_msg_buffer 且 mgr is not None 则回放，再处理当前消息。

问题：回放依赖“有新的 WS 消息到达”。若某段时间内没有任何新消息（例如行情静默、仅有一个已成交订单的推送），则缓冲里的订单成交/取消消息永远不会被回放。对应订单的 tracking 只能等 _monitor_order 超时后走 HTTP 兜底；若 HTTP 也失败或延迟，会误判为 TIMEOUT，即已成交却被判为超时。

典型场景：WS 重连或启动顺序异常导致短时间内 mgr is None，订单消息被缓冲；之后若长时间无 K 线/无其他订单推送，缓冲不回放，该订单会拖到超时。

建议：

• 在“有订单被追踪”的前提下，即使无新 WS 消息，也周期性（例如每 2–5 秒）检查 _order_msg_buffer 且 mgr is not None 时执行回放；和/或
• 在 track_order 注册时若发现缓冲区非空且 mgr 已就绪，立即做一次回放（确保该 oid 的已到达消息被处理）。

2.2 关闭时未解析未完成订单，可能导致进程卡在 wait_for_order（高）

位置：

• websocket_order_manager.py：_monitor_order 以 daemon=True 启动（约 141–143 行）。
• 服务停止时仅设置 stop_event、停 orchestrator/WS，没有对 WebSocketOrderManager 中仍为 PENDING 的 tracking 做“强制解析”（如 TIMEOUT 或 CANCELED）并 result_event.set()。

问题：

• 若主流程（或策略线程）正阻塞在 wait_for_order(tracking)，而对应的 _monitor_order 是唯一会调用 _resolve 的路径。
• 进程退出时 daemon 线程会被直接终止，_resolve 可能永远不执行，result_event 永远不会 set。
• 等待线程会一直阻塞在 tracking.result_event.wait()，导致进程无法干净退出（需强杀）。

建议：

• 在服务/orchestrator 的 stop() 中，调用 manager 的“关闭”方法：对当前所有 _tracking 中 PENDING 的订单做一次强制解析（例如 TIMEOUT）并 result_event.set()；和/或
• 将 _monitor_order 改为非 daemon，并在 shutdown 时通过共享的 stop_event 让 monitor 主动对未完成订单做一次 HTTP 检查或强制 TIMEOUT 后 resolve，再退出。

2.3 HTTP 返回 FILLED 但 avgPx/totalSz 为 0 时，has_fill_price 与 filled 数据不设（中高）

位置：websocket_order_manager.py 约 269–278 行。

逻辑：HTTP/超时模式下，当 final_status == OrderStatus.FILLED 时：

• 仅当 px > 0 时设置 tracking.avg_price 和 tracking.has_fill_price = True；
• 仅当 sz > 0 时设置 tracking.filled_size。

问题：若交易所/API 返回 status=filled 但 avgPx/totalSz 缺失或为 0，则 tracking.avg_price、tracking.filled_size 保持为 0，has_fill_price 仍为 False。下游 executor 会走 _backfill_order_price；若此时 HTTP 再失败或仍无数据，成交价和成交量会一直为 0，影响记录与风控。

建议：对 HTTP 返回 FILLED 的情况，只要 status == FILLED 就至少将 has_fill_price 设为 True（或按“有 px 或 sz 任一有效”来设），并尽量用 limitPx 等做兜底价格，避免下游误以为“无成交价”而依赖可能失败的 backfill。

3. 中低风险 / 边界情况

3.1 无 tid 时用 (oid, px, sz, time) 哈希去重可能误去重（中低）

位置：websocket_order_manager.py _fill_key（约 82–90 行）、_on_user_fill 中按 fid 去重。

问题：当 fill 无 tid 时用 oid+px+sz+time 的 MD5 做唯一键。若交易所对同一笔成交发了两条相同 (oid, px, sz, time) 的 userFills（例如重连重放），会被正确去重；但若存在两笔不同成交恰好 (px, sz, time) 相同（同一秒同价同量），会被误判为重复，少计一笔成交量。

建议：若 API 支持，优先使用交易所唯一 fill id；若无，可在 key 中加入更多字段（如 side、fee 等）降低碰撞概率，并打日志便于排查。

3.2 verify_pending_orders 重试列表使用“快照”的 (oid, tracking)（低）

位置：websocket_order_manager.py 约 176–206 行。

逻辑：先取 pending = [(oid, t) for ...]，再对部分 oid 做重试；失败时对 retry_list 中的 (oid, tracking) 调用 _resolve(oid, tracking, OrderStatus.TIMEOUT)。

分析：若在第一次循环中某 oid 已被替换（新一轮 track_order(oid)），则 retry 时传入的 tracking 是旧对象，_resolve 内 identity check 会失败，不 resolve。旧 tracking 已在 track_order 里被设为 CANCELED 并 result_event.set()，故不会造成永久阻塞。当前设计可接受，仅需注意不要依赖“重试一定 resolve 该 oid”的假设。

4. 已做较好的设计点（无 bug）

• Identity check：HTTP/超时路径传入的 tracking 与 _tracking.get(oid) 比较，避免误操作被替换的 tracking。
• 重复 oid 追踪：track_order 时旧 tracking 被设为 CANCELED 并 result_event.set()，不会永久阻塞。
• 唯一解析路径：所有终态都经 _resolve()，并在持锁内 pop + set result_event，避免重复 resolve 与竞态。
• 早期 HTTP 检查：2s 早期检查可缓解“WS filled 先于 track_order 到达”导致的误等。
• 宽限期 + fallback 价：orderUpdates 先到且无 userFills 时用 fallback 价并设 grace timer，逻辑一致；WS 模式不设 has_fill_price 以触发 executor 的 backfill 是刻意设计。

5. 小结与修复优先级

优先修复 2.1 和 2.2，可显著降低错误超时与进程无法退出的风险；再按需处理 2.3 和 3.1。