getDomain/docs/ops_center_runtime/HANDOFF_20260419_0332.md

HANDOFF 2026-04-19 03:32

本轮做了什么

这轮没有扩功能，没有进新页面，也没有碰发布动作。

只做了两件事：

1. 把检测执行停滞的判断继续收紧
2. 对 worker 控制消息链补上最小代码修复

当前最新判断

当前不是接管问题，也不是日志回传问题。

当前真实状态是：

• remote_access_ready = 3/3
• log_sync_state = full_capture
• 大陆首批结果同步已经成功过
• 但检测任务没有持续前进

这个停滞目前有两层原因：

第一层：已确认的现场阻塞

• mainland-controller-01 代理池刷新后 0 available
• 代理源可以拉到原始代理
• 但抽样校验全部失败

这会直接影响 controller 侧吞吐。

第二层：刚补好的代码风险

之前存在一个运行态风险：

• 控制面发 start_detection
• Redis publish 成功
• 但 worker 如果漏收 pubsub 消息
• pending 指令可能不会在运行态被再次消费

这会造成：

• 页面像是发起成功了
• 但 worker 不一定真的继续推进

现在这处代码缺口已经补上，但还没有完成线上部署验证。

本轮代码修复

1. worker_control_service

文件：

• domain-api/app/services/worker_control_service.py

修复：

• 每条 worker 控制消息补 request_id
• Redis publish 和 pending fallback 复用同一条消息体

2. detect_worker

文件：

• domainCheck/detect_worker.py

修复：

• 运行态心跳里周期性补偿消费 pending 控制消息
• 真正收到控制消息后，按 request_id 清理 pending

3. 新增测试

文件：

• domain-api/tests/test_worker_control_service.py

验证目标：

• 确保 send_worker_command(...) 会生成并持久化 request_id

本地验证结果

已通过：

PYTHONPATH=/www/wwwroot/getDomain/domain-api /opt/domaincheck/domainCheck/.venv/bin/python -m 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

下一轮唯一该做什么

下一轮不要发散，只做最小部署验证：

1. 大陆节点拉最新代码
2. 重启 domaincheck-worker
3. 复查：
   • /api/v1/detect/job/active
   • /api/v1/runtime/sync-summary
   • controller / worker scene-log
   • 必要时再采集 domaincheck-worker 日志
4. 只判断两件事：
   • 修复上线后，检测任务是否恢复推进
   • 如果仍不推进，是否只剩 controller 代理池 0 available 这个现场阻塞

现在不要做什么

• 不做新页面
• 不做新模块
• 不做控制面增强
• 不做发布动作
• 不把问题再泛化成“日志没回来”或“接管没完成”

一句话结论

当前最准确的状态是：

• 接管和同步基本已经闭合
• 检测执行停滞仍然存在
• worker 控制消息补偿链已补代码
• 下一步只剩“拉代码重启 worker 后看任务是否恢复推进”