数据自愈并发优化设计方案 一、现状分析 当前流程 _run_data_healing（realtime_kline_service_base.py:1807）： for (symbol, base_symbol) in heal_pairs: # ~50+ 配对，串行 DataHealingOrchestrator(...) # → RepairExecutor.__init__ │ # → KlineDataFiller.__init__ │ # → Info(MAINNET_API_URL) HTTP 握手 ~0.85s │ # ← 第 2-50 个握手完成后才被 shared_executor 覆盖，全部浪费！ _load_zscore_history()
数据自愈并发优化设计方案 一、现状分析 当前流程 _run_data_healing（realtime_kline_service_base.py:1807）： for (symbol, base_symbol) in heal_pairs: # ~50+ 配对，串行 DataHealingOrchestrator(...) # → RepairExecutor.__init__ │ # → KlineDataFiller.__init__ │ # → Info(MAINNET_API_URL) HTTP 握手 ~0.85s │ # ← 第 2-50 个握手完成后才被 shared_executor 覆盖，全部浪费！ _load_zscore_history()
数据自愈并发优化设计方案 一、现状分析 当前流程 _run_data_healing（realtime_kline_service_base.py:1807）： for (symbol, base_symbol) in heal_pairs: # ~50+ 配对，串行 DataHealingOrchestrator(...) # → RepairExecutor → KlineDataFiller │ # Info(MAINNET_API_URL) HTTP 握手 ~0.85s │ # 第 2-50 个立刻被 shared_executor 覆盖，全部浪费！ _load_zscore_history() # DB 查询 ×1（0.08-0.56s）
数据自愈模块优化设计文档 版本：v1.0 日期：2026-02-23 范围：src/utils/data_healing/ + src/services/realtime_kline_service_base.py（_run_data_healing 部分） 目录 1. 问题全景与优先级总表 2. BUG-01：加载语义与修复语义不一致 3. BUG-02/03：单条/少量记录无法生成修复目标 4. BUG-04：日志误导性 5. BUG-05：重复写入（BUG-01 副作用） 6. BUG-06：test_basic.py 与 Diagnosis 定义失同步 7.
数据自愈模块综合问题分析报告 Context 本分析旨在全面梳理 src/utils/data_healing/ 数据自愈模块存在的各类问题，结合三份参考文档（数据自愈BUG Cursor 1.md、数据自愈BUG Cursor 2.md、启动性能优化设计文档.md）及代码实地核查，形成统一的问题清单与修复优先级建议。 一、模块架构速览 DataHealingOrchestrator.heal_and_prepare() Phase 1 : _load_zscore_history() ← SQL 时间窗口加载 Phase 2–3: 诊断-修复循环（最多3轮） ├─ _diagnose() ← 三项检查（连续性/新鲜度/数量） │ ├─ ContinuityChecker.check_continuity() │ └─ _check_freshness() ├─ RepairExecutor.
启动性能优化设计文档：数据自愈并行化 + 预过滤 一、问题现象 每次启动时，日志中出现大量类似以下输出，耗时数分钟才能完成启动： KlineDataFiller 初始化完成 | 交易所: hyperliquid 数据自愈编排器初始化 | VINE/USDC:USDC vs AAVE/USDC:USDC | timeframe: 4h 数据自愈启动 | 需要 3 条 | 间隔 240min | 理论跨度: 12h 数据不足: 2 条（12h 窗口），尝试更大范围 加载历史数据: 3 条 （16h 窗口，需要 12h） ...（每对重复一次）... 自愈失败: ADA/USDC:USDC | 完整度: 33.
KlineDataFiller 与 KlineDataFillerLazy 说明 本文档说明 kline_data_filler.py 与 kline_data_filler_lazy.py 两个模块的差异、在项目中的调用方式，以及为何通用服务与 HYPE 服务使用不同的类。 一、模块关系与技术差异 1.1 角色关系 * kline_data_filler.py：基类 KlineDataFiller，实现完整的 K 线校验与补充逻辑（连续性校验、窗口长度校验、冷却、拉取并写入等）。 * kline_data_filler_lazy.py：子类 KlineDataFillerLazy，继承 KlineDataFiller，仅改变「何时、如何创建
代码质量审计报告 日期：2026-02-23 审计范围：src/services/、src/trading/、src/utils/、src/scripts/、src/config.py 一、死代码 1.1 _safe_float() / _safe_int() — services 中重复定义 * 文件：src/services/realtime_kline_service_base.py:509–547 * 问题：_safe_float() 和 _safe_int() 作为静态方法定义在 RealtimeKlineServiceBase，但 src/trading/config.py 中已有同名同功能的独立函数，形成跨模块重复定义
数据自愈模块启动期 BUG 分析报告（Cursor 2） 基于 realtime_kline_service 启动日志与代码阅读的根因归纳。 1. 「尝试更大范围」未真正扩大窗口 现象（日志） * 出现「数据不足: 1 条（24h 窗口），尝试更大范围」后，没有再出现「加载历史数据: N 条（48h/72h 窗口）」。 * 直接进入「第 1 轮检查...」，最终「无法确定修复目标」。 根因（代码） orchestrator.py 中 _load_zscore_history 的时间窗口是写死三档： needed_hours = (required_count * self.
数据自愈模块修复执行报告 日期：2026-02-23 提交范围：src/utils/data_healing/ × 2 文件 + src/services/realtime_kline_service_base.py 变更统计：+50 行 / −111 行，净减少 61 行 一、问题背景 服务启动时数据自愈运行约 19 分钟（498 对配对），HEALING_TIMEOUT_SECONDS=300 完全无效。 根本原因：signal.alarm() 触发的 TimeoutError 是 Exception 的子类（继承链：TimeoutError → OSError → Exception）。闹钟一次性触发后，
数据自愈模块冗余分析报告 日期：2026-02-23 审计范围：src/utils/data_healing/ 全部 5 个文件 + 调用方 _run_data_healing() 一、代码规模 文件 总行数 类/dataclass 方法数 orchestrator.py 557 3 / 2 16 repair_executor.py 372 1 / 0 11 quality_assessor.py 118 2 / 1 4 continuity_checker.py 99 1 / 0 2 config.
数据自愈超时机制失效分析 日期：2026-02-23 问题：HEALING_TIMEOUT_SECONDS=300 无效，服务启动时数据自愈运行 ~19 分钟（498 对配对） 一、现象 09:20:16 - 数据自愈启动 | 498 个配对 | timeout=300s 09:25:16 - app - ERROR - 数据库连接错误: 数据自愈超时 (300秒) ← 超时触发了，但... 09:25:16 - orchestrator - ERROR - 加载历史数据失败 - 数据库错误: 数据自愈超时
数据自愈启动缓慢与修复无效：根因与修复方案 现象（来自日志） * 每次启动都对多个交易对（如 EIGEN、MOVE、FARTCOIN 等）做数据自愈。 * 部分对子始终显示「数量不足(2/3)」，连续 3 轮修复，每轮都「Level 1修复完成: 成功=1, 实际写入 1 条记录」。 * 3 轮后仍为「自愈结果: degraded | D级 (66.7%) | 数据量: 2 条」——修复没有提升可见条数。 完整因果链：输入 → 状态变化 → 调用路径 → 出错点 → 根因 1. 输入（Trigger） 项目 说明 入口 实时
数据自愈超时机制失效分析 日期：2026-02-23 问题：HEALING_TIMEOUT_SECONDS=300 无效，服务启动时数据自愈运行 ~19 分钟（498 对配对） 一、现象 09:20:16 - 数据自愈启动 | 498 个配对 | timeout=300s 09:25:16 - app - ERROR - 数据库连接错误: 数据自愈超时 (300秒) ← 超时触发了，但... 09:25:16 - orchestrator - ERROR - 加载历史数据失败 - 数据库错误: 数据自愈超时
订单跟踪系统 — 复杂度审计报告 审计范围：src/trading/executor.py · src/trading/websocket_order_manager.py 验证方式：静态分析 + 测试网实测（scripts/verify_order_tracking.py --coin ICP --size 10） 一、审计结论 发现 5 项复杂度问题，根源均为对 Hyperliquid API 响应结构的错误假设。 测试网验证推翻了两个核心前提： 假设 实测结果 query_order_by_oid 返回 avgPx / totalSz 从不返回，两字段对任意状态均缺失 userFills 比 orderUpdates 晚到
订单追踪系统 Bug 修复设计文档 背景 对两份 Bug 报告进行代码核实后，确认以下情况： 报告误判（不需要修） * B1 双 EventBus：EventBus 是单例（__new__ + 双重检查锁），EventBus() 永远返回同一实例，不存在隔离问题 * B3 Grace Timer 竞态：_resolve 在 lock 内执行 pop(oid)，第二次调用时 identity check 失败直接 return，天然幂等 * B8 TOCTOU：_check_order_after_cancel 函数不存在，_close_limit_leg_timeout 降级路径已有 fill_px
订单跟踪系统严重 Bug 因果链分析报告 分析日期：2026-02-23 项目路径：Trading-in-websocket 分析范围：订单跟踪系统（WebSocket 事件、并发控制、数据一致性） 因果链格式：输入 → 状态变化 → 调用路径 → 出错点 → 根因 概览 发现 5 个 CRITICAL/P0 级 + 3 个 HIGH 级 Bug，分布于 EventBus 隔离、死锁、竞态、数据错误等方面。 严重等级汇总 Bug # 标题 严重等级 核心后果 B1 双 EventBus 隔离 P0 / 静默失效 WS 所有订单/
订单跟踪严重 Bug 完整因果链分析 本文档汇总当前系统订单跟踪存在的严重 bug，按「输入 → 状态变化 → 调用路径 → 出错点 → 根因」建立完整因果链。 架构与数据流概览 flowchart LR subgraph input [输入源] WS_Order[orderUpdates WS] WS_Fill[userFills WS] end subgraph pub [发布端] EWM[EnhancedWebSocketManager] EB_WS[EventBus_WS] end subgraph sub [订阅端] EB_Exec[EventBus_Exec] WOM[WebSocketOrderManager] Exec[Executor] end WS_
订单跟踪系统严重 Bug 分析报告 分析日期：2026-02-22 项目路径：Trading-in-websocket 分析范围：订单跟踪系统（OrderFilledEvent、WebSocket消息处理、并发控制、数据一致性） 概览 发现 7 个严重 Bug 和 3 个设计问题，涉及竞态条件、死锁、内存泄漏、数据一致性等方面。 严重等级汇总 Bug # 标题 严重等级 核心影响 BUG #1 Grace Timer 竞态条件 CRITICAL 订单二重结算、金额错误 BUG #2 Timer 内存泄漏 HIGH 内存溢出、系统崩溃 BUG #3 Fill Price 为
订单跟踪严重 Bug 分析 本文档汇总当前系统订单跟踪存在的严重与重要 bug，及修复优先级建议。 1. 最严重：双 EventBus 隔离，订单事件永远收不到（核心功能静默失效） 现象：OrderStatusEvent、OrderFilledEvent 由交易 WS 发布，但 WebSocketOrderManager 订阅的是另一条总线，导致所有通过 WebSocket 的订单状态与成交事件均未被消费。 根因： * Executor 在 src/trading/executor.py 中创建自己的 self._event_bus = EventBus()，并传给 WebSocketOrderManager(executor=self, event_bus=self._event_bus)（约 L89、L146）。 * 交易
Bug 3 修复报告：限价单部分成交跟丢 & 孤儿仓位误报 修复日期：2026-02-23 涉及文件：4 个 修改性质：逻辑修复 + 旧代码彻底清理 一、问题描述 复现场景 以 ICP/USDC 为例： * 下限价单：origSz = 142.24 ICP，限价 2.1078 * 追踪超时（默认 600s），触发撤单 * 交易所实际成交：72.09 ICP（部分成交后撤单） * 系统报告："开仓失败（超时未成交）" * 副作用：72.09 ICP 的真实仓位无人管理，触发"
订单部分成交 Bug — 根因分析与 WS 优先修复方案 测试网实战复盘，2026-02-22 22:30–22:40，ICP 限价单场景 一、现象还原 告警序列 时间 告警 说明 22:30:00 📤 限价单已挂出: ICP 订单 48939226203，142.24 ICP @ 2.1078 ~22:31:00 🎴 真孤儿仓位收纳: ICP/USDC:USDC 来源: sync，大小: 12.19，数据库无记录 ~22:40:00 ❌ 限价单timeout: ICP 错误:
Bug 3 最优修复方案：限价单部分成交跟丢 关联文档：订单系统bug3_限价单跟丢与孤儿仓位误报.md 一、问题重述与根因校正 现象 限价单部分成交（72.09 ICP）后触发超时撤单，系统误报「开仓失败」，产生孤儿仓位告警。 原文档根因描述有误 原文档称："totalSz 仅出现在 WS orderUpdates 推送消息中"。 实测不符：WS orderUpdates 消息字段为： order.oid 订单 ID order.limitPx 挂单价 order.sz 当前剩余委托量（非累计成交量） order.origSz 原始委托量 item.status 订单状态 totalSz（
订单部分成交 Bug — 根因、WS 修复方案与设计 测试网实战复盘，2026-02-22 22:30–22:40，ICP 限价单场景 一、现象还原 告警序列 时间 告警 说明 22:30:00 📤 限价单已挂出: ICP 订单 48939226203，142.24 ICP @ 2.1078 ~22:31:00 🎴 真孤儿仓位收纳: ICP/USDC:USDC 来源: sync，大小: 12.19，数据库无记录 ~22:40:00 ❌ 限价单timeout: ICP 错误: