Fix worker control fallback for running detect workers

docs/ops_center_runtime/IMPLEMENTATION_STATUS.md

@@ -1,22 +1,22 @@
 # IMPLEMENTATION_STATUS
 
-更新时间：2026-04-19 03:00 CST
+更新时间：2026-04-19 03:38 CST
 
 ## 当前真实状态
 
 阶段判断：
 
 - 海外单脑接管能力：约 `95%`
-- 分布式检测真实执行能力：约 `94%`
-- 距离“可稳定上线并放心用后台发起检测”：约 `93%~94%`
+- 分布式检测真实执行能力：约 `88%~90%`
+- 距离“可稳定上线并放心用后台发起检测”：约 `86%~89%`
 
 ## 本轮最新结论
 
-这轮只做了只读复查，结论更明确了：
+这轮结论需要更新为三段：
 
-- 中央接收 `detect_result_projection` 的代码已经就位
-- `sync_agent` 自动产 `detect_result_projection` 的代码也已经就位
-- 但 mainland 端当前仍未真正跑到新版 `domaincheck-sync-agent`
+- 接管与同步能力已经明显趋于完成
+- 检测执行面当前没有持续产出
+- 其中一处代码级风险已经完成最小修复，但尚未完成线上部署验证
 
 ## 当前证据拆分
 
@@ -27,19 +27,119 @@
 - `detect_result_projection` 支持 `recent_domain_events`
 - 中央 ingest 会把逐条事件写入 `detect_run_events`
 - `sync_agent` 会自动产出 `detect_result_projection`
+- worker 控制消息新增 `request_id`
+- worker 运行态心跳会补偿消费 pending 控制消息
+- worker 收到并处理控制消息后会按 `request_id` 清理 pending 指令
 
-### 2. 真实运行闭环
+本地代码验证已通过：
 
-当前仍未完成：
+- `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`
 
-- `runtime_ingest` 持续刷新
-- `detect_result_ingest` 没有刷新
-- mainland `domain_*` 事件仍为 0
+### 2. 接管/同步闭环
+
+当前已完成：
+
+- `remote_access_ready = 3/3`
+- `log_sync_state = full_capture`
+- `mainland-controller-01` 的 `domaincheck-sync-agent` 已重启到新进程
+- 首轮 `detect_result_projection` 推送成功过一次
+- 中央已收到 mainland 首批 `domain_*` 事件
 
 这说明：
 
 - mainland 到中央的基础同步链是活的
-- 但 mainland 目前还没有跑到新版 `sync_agent`
+- 结果投影链至少成功打通过一次
+
+### 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` 的外部执行阻塞
+
+所以当前最准确的状态是：
+
+- 代码级控制链缺口已补上
+- 运行态是否恢复，还要看线上节点拉代码重启后的观测结果
 
 ## 当前已闭合的问题
 
@@ -54,46 +154,60 @@
 
 ## 当前唯一剩余问题
 
-当前唯一剩余问题：
+当前唯一主问题仍然是：
 
-- mainland 节点尚未完成“拉新代码并重启 `domaincheck-sync-agent`”
+- 检测执行面停滞
+
+但其下应拆成两个层次：
+
+- 已补代码、待验证：
+  - worker 控制消息补偿消费链
+- 已确认现场阻塞：
+  - controller 代理池可用性为 0
+  - 因此没有持续产生新的 domain 级结果
 
 换句话说：
 
 - 现在不是逻辑未实现
 - 不是中央映射失败
-- 也不是检测任务没跑
-- 而是 mainland 仍在跑旧版 `sync_agent`
+- 不是节点未接管
+- 而是执行现场没有继续产出，且 controller 侧卡在代理校验失败
+
+## acceptance 当前状态
+
+最新接管验收结果仍然成立：
+
+- `pbr-9ce5c85f17`：`onboarding.acceptance` 成功
+- `pbr-389abd618c`：`onboarding.acceptance` 成功
+
+旧的 `attention` run 依然是历史残留，但它们已经不是当前最真实的生产阻塞。
 
 ## 当前是否可以继续跑检测测试
 
 当前结论：
 
-- 可以继续跑检测测试
-- 主统计和节点参与已经可信
-- 但中央逐条账本仍不能视为 mainland 最终真相
+- 可以继续做最小部署验证
+- 也可以继续做执行恢复类排查
+- 但还不能把当前状态视作“后台检测已经稳定恢复”
 
 ## 当前是否建议直接上线
 
 当前结论：
 
-- 如果目标是：
-  - 后台稳定发起检测
-  - 看懂谁在跑
-  - 看懂整体任务推进
-  那已经基本可用
+- 不建议现在按“可稳定上线”判断
 
-- 如果目标是：
-  - 中央逐条反映大陆每个域名的终态
-  那还差最后一个外部动作：
-  - mainland 拉新
-  - 重启 `domaincheck-sync-agent`
+原因不是接管面，而是执行面：
+
+- 三台节点都已接入
+- 但当前任务没有持续吞吐
+- controller 代理池全部验不过会直接影响检测产出
+- 并且这轮刚补上的 worker 控制消息修复还没经过线上运行验证
 
 ## 当前优先级判断
 
 最高优先级：
 
-- `J1-大陆逐条结果同步前置批`
+- `J2-检测执行停滞收口批`
 
 当前不应继续推进：
 
@@ -101,12 +215,20 @@
 - 新模块
 - 新页面
 - 发布动作
-- 与逐条结果同步无关的工作
+- 与检测执行停滞无关的工作
 
 ## 完成下一轮后的预期
 
-如果下一轮完成 mainland 拉新并重启 `domaincheck-sync-agent`，并验证贯通：
+如果下一轮确认：
 
-- mainland `domain_*` 会进入中央
-- item 级统一才会真正可落地
-- 整体可上线程度预计提升到 `95%~96%`
+- 大陆节点已拉到这版控制消息修复
+- `domaincheck-worker` 重启后稳定收新指令
+- controller 代理池恢复可用
+- `domain_*` 开始继续增长
+- `items_completed` 和近窗吞吐重新前进
+
+则整体可上线程度预计可回升到：
+
+- `92%~94%`
+
+在那之前，当前口径应保持保守。