getDomain/docs/ops_center_runtime/IMPLEMENTATION_STATUS.md

IMPLEMENTATION_STATUS

更新时间：2026-04-19 03:38 CST

当前真实状态

阶段判断：

• 海外单脑接管能力：约 95%
• 分布式检测真实执行能力：约 88%~90%
• 距离“可稳定上线并放心用后台发起检测”：约 86%~89%

本轮最新结论

这轮结论需要更新为三段：

• 接管与同步能力已经明显趋于完成
• 检测执行面当前没有持续产出
• 其中一处代码级风险已经完成最小修复，但尚未完成线上部署验证

当前证据拆分

1. 代码闭环

已经完成：

• detect_result_projection 支持 recent_domain_events
• 中央 ingest 会把逐条事件写入 detect_run_events
• sync_agent 会自动产出 detect_result_projection
• worker 控制消息新增 request_id
• worker 运行态心跳会补偿消费 pending 控制消息
• worker 收到并处理控制消息后会按 request_id 清理 pending 指令

本地代码验证已通过：

• unittest domain-api/tests/test_worker_control_service.py
• python -m py_compile domainCheck/detect_worker.py domain-api/app/services/worker_control_service.py

2. 接管/同步闭环

当前已完成：

• remote_access_ready = 3/3
• log_sync_state = full_capture
• mainland-controller-01 的 domaincheck-sync-agent 已重启到新进程
• 首轮 detect_result_projection 推送成功过一次
• 中央已收到 mainland 首批 domain_* 事件

这说明：

• mainland 到中央的基础同步链是活的
• 结果投影链至少成功打通过一次

3. 检测执行闭环

当前未完成：

• 连续 40 秒观察窗口内：
  • progress_percent 不变
  • items_completed 不变
  • items_running 不变
  • items_claimed 不变
  • items_pending 不变
• mainland domain_* 事件数仍固定在 10
• 最新 mainland detect_result_ingest 仍停在 5382
• activity-stream 明确提示：
  • 近窗刚有吞吐 0 台

这说明：

• 当前不是单纯“页面没刷新”
• 而是执行现场这段时间没有继续出结果

本轮新增硬证据

通过中央观测面、节点现场日志和远端 domaincheck-worker 日志，已确认：

• mainland-controller-01 现场日志显示：
  • 当前可用代理数: 0
  • 最近结果: 刷新成功，可用 0 个
• controller 新增远端日志显示：
  • 代理源拉取成功
  • 抽样校验后 共 0 个可用代理
  • 失败集中在：
    • ProxyError@https://m.baidu.com
    • Unable to connect to proxy
    • ConnectTimeoutError
• worker 新增远端日志显示：
  • 时光机检测 外部依赖异常，步骤降级继续执行
  • 同时仍有 域名检测完成
  • 新收到的重复启动指令被忽略，因为任务已在运行
• 两台大陆节点 full capture 已开启，但源日志时间没有继续前进

这说明：

• 当前第一主阻塞更像 controller 代理池不可用
• worker 的时光机异常是客观存在的次级问题
• 不是控制面未接管
• 不是同步链未打通

本轮新增代码修复

本轮不是只停留在诊断，还补了一处运行态最小修复：

修复点 1：控制消息唯一标识

• 文件：
  • domain-api/app/services/worker_control_service.py
• 变更：
  • 每次 send_worker_command(...) 都附带 request_id
  • Redis publish 与 pending fallback 使用同一份消息体

修复点 2：worker 运行态补偿消费 pending 指令

• 文件：
  • domainCheck/detect_worker.py
• 变更：
  • 心跳线程每轮会补偿尝试消费 pending 控制消息
  • 解决“worker 在线但 pubsub 消息漏收，导致 pending 指令长期不被消费”的风险

修复点 3：worker 收到指令后确认清理 pending

• 文件：
  • domainCheck/detect_worker.py
• 变更：
  • worker 实际收到控制消息后，会按 request_id 清理对应 pending 指令
  • 避免修复后又产生重复回放

当前判断

这组修复解决的是：

• “检测启动已经发布，但 worker 可能静默漏收”的代码风险

这组修复还没有证明能够解决的是：

• controller 代理池校验后 0 available 的外部执行阻塞

所以当前最准确的状态是：

• 代码级控制链缺口已补上
• 运行态是否恢复，还要看线上节点拉代码重启后的观测结果

当前已闭合的问题

已闭合：

• 大陆 controller 无法 pull_tasks
• Detect 页面误判“大陆没跑”
• Detect 主统计口径不一致
• Runtime / Queue / Detect 主摘要不统一
• 中央逐条事件接收缺口
• sync_agent 自动产出结果投影缺口

当前唯一剩余问题

当前唯一主问题仍然是：

• 检测执行面停滞

但其下应拆成两个层次：

• 已补代码、待验证：
  • worker 控制消息补偿消费链
• 已确认现场阻塞：
  • controller 代理池可用性为 0
  • 因此没有持续产生新的 domain 级结果

换句话说：

• 现在不是逻辑未实现
• 不是中央映射失败
• 不是节点未接管
• 而是执行现场没有继续产出，且 controller 侧卡在代理校验失败

acceptance 当前状态

最新接管验收结果仍然成立：

• pbr-9ce5c85f17：onboarding.acceptance 成功
• pbr-389abd618c：onboarding.acceptance 成功

旧的 attention run 依然是历史残留，但它们已经不是当前最真实的生产阻塞。

当前是否可以继续跑检测测试

当前结论：

• 可以继续做最小部署验证
• 也可以继续做执行恢复类排查
• 但还不能把当前状态视作“后台检测已经稳定恢复”

当前是否建议直接上线

当前结论：

• 不建议现在按“可稳定上线”判断

原因不是接管面，而是执行面：

• 三台节点都已接入
• 但当前任务没有持续吞吐
• controller 代理池全部验不过会直接影响检测产出
• 并且这轮刚补上的 worker 控制消息修复还没经过线上运行验证

当前优先级判断

最高优先级：

• J2-检测执行停滞收口批

当前不应继续推进：

• 新控制面功能
• 新模块
• 新页面
• 发布动作
• 与检测执行停滞无关的工作

完成下一轮后的预期

如果下一轮确认：

• 大陆节点已拉到这版控制消息修复
• domaincheck-worker 重启后稳定收新指令
• controller 代理池恢复可用
• domain_* 开始继续增长
• items_completed 和近窗吞吐重新前进

则整体可上线程度预计可回升到：

• 92%~94%

在那之前，当前口径应保持保守。