admin/getDomain

Fork 0

Files

Your Name c33f4f194b Fix worker control fallback for running detect workers

2026-04-19 03:32:56 +08:00

7.8 KiB

Raw Blame History

TASK_BOARD

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

当前主批次

唯一主批次：J2-检测执行停滞收口批

目标：

不进入新页面
不扩展控制面
不新增发布动作
只收口当前唯一真实阻塞：
- 节点已接管
- 同步已打通
- 但检测执行没有继续产出新结果

本轮最新状态

本轮在只读取证基础上，已经补了一处最小代码修复，但还没有完成线上节点拉代码后的运行验证。

已完成的最小修复

worker_control_service.send_worker_command(...)
- 为每条 worker 控制消息补上 request_id
- 保证 Redis 发布与 pending fallback 使用同一份负载
detect_worker
- 在运行态心跳里周期性补偿消费 pending 控制消息
- 在真正收到控制消息后，按 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

仍未完成的事情

大陆节点尚未基于这版修复完成拉代码并重启 domaincheck-worker
因此这轮还不能把“检测停滞”完全归因成单一外部代理问题
当前更准确的表述应为：
- controller 代理池可用数为 0 是已确认现场阻塞
- worker 控制消息存在“可能丢发布、pending 不被运行态补偿消费”的代码风险，现已本地修复，待线上验证

本轮最新复查结果

本轮没有新增实现，只做了中央只读复查 + 节点现场日志取证 + 远端 domaincheck-worker 日志采样：

活跃任务仍是 detect-20260417170546-96023e
三台节点都在参与：
- mainland-controller-01
- mainland-worker-01
- overseas-control-01
但连续一个完整观察窗口内，任务进度没有前进：
- completed = 21
- running = 14
- claimed = 34
- pending = 931
mainland domain_* 事件仍停在 10 条，没有继续增长
最新 mainland detect_result_ingest 仍是：
- id = 5382
- created_at = 2026-04-19 03:10:14
activity-stream 已明确显示：
- 近窗刚有吞吐 0 台
新增日志采样结果：
- mainland-controller-01
  - 代理源拉取成功
  - 代理校验后 共 0 个可用代理
- mainland-worker-01
  - 时光机依赖异常会降级继续执行
  - 收到重复启动指令时会忽略

关键证据

证据 1：接管与同步已通

当前中央状态：

remote_access_ready = 3/3
log_sync_state = full_capture
mainland controller 的 domaincheck-sync-agent 已在新进程上运行

说明：

当前不是接管问题
也不是日志回传问题
更不是同步链完全断开

证据 2：检测任务当前没有继续出新结果

连续 40 秒前后对比结果完全一致：

JOB_PROGRESS = 2.1
items_completed = 21
items_running = 14
items_claimed = 34
items_pending = 931

说明：

当前不是“页面慢一拍”
而是执行面这段时间确实没有继续产出

证据 3：中央 mainland 逐条结果没有继续增长

当前中央查询结果：

mainland domain_started/domain_completed/domain_failed/domain_blacklisted
- 仍为 10
最新 mainland detect_result_ingest
- 仍为 5382

说明：

首批同步成功过
但后续并没有继续流入新逐条结果

证据 4：controller 现场日志已指向代理池可用性为 0

mainland-controller-01 现场日志显示：

当前可用代理数: 0
最近结果: 刷新成功，可用 0 个
免费检测链包含：
- 注册查询
- 百度 site
- 360 site
- 站长之家
- 爱站
- 时光机

进一步的远端 logs.collect(domaincheck-worker) 结果显示：

controller 能从 6 个代理源成功拉到原始代理
但在抽样验证后：
- 代理池刷新完成，共 0 个可用代理
失败原因集中在：
- ProxyError@https://m.baidu.com
- Unable to connect to proxy
- ConnectTimeoutError

说明：

当前不是代理源接口没返回
而是“拿到的代理全部验不过”
主阻塞已经可以精确收紧到 controller 代理池不可用

证据 5：worker 的时光机异常存在，但不是第一主因

mainland-worker-01 的远端 domaincheck-worker 日志显示：

存在：
- 时光机检测外部依赖异常，步骤降级继续执行
同时仍可见：
- 域名检测完成
最近收到控制消息后：
- 收到启动检测指令，但检测任务已在运行，忽略重复启动

说明：

worker 并不是完全不能执行
时光机异常是客观存在的次级问题
但它不像 controller 代理池为 0 那样直接卡住整体吞吐

证据 6：full_capture 已开启，但源日志时间没有继续前进

节点现场日志最新可见记录仍停在较早时间：

mainland-controller-01
- 最近样本集中在 01:00:23
mainland-worker-01
- 最近样本集中在 01:00:35

额外 35 秒观察窗口结果：

capture_at 没有继续前进
source_msg 里的源日志时间也没有继续前进

说明：

不是“全量日志没开”
也不是“日志回传没回来”
而是执行进程这段时间确实没有继续产生日志

证据 7：worker 控制消息补偿链已补上代码缺口

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

runtime.start_detection 成功只代表“控制消息已发布到 Redis”
如果 worker 在线但恰好漏收了 pubsub 消息
pending 指令只在启动或重连时消费，就可能造成：
- 页面显示“已启动”
- 但 worker 实际没有进入新的执行流

当前已完成最小修复：

每条控制消息带 request_id
worker 心跳会主动补偿消费 pending 指令
worker 真正收到并处理后，会按 request_id 清理 pending

这一步已经消除了“控制消息可能被静默漏掉”的代码风险，但还需要线上部署后再观察真实任务是否恢复推进。

当前结论

当前结论要收敛成一句话：

接管链路已基本完成
同步链路已至少成功贯通一次
当前主阻塞依旧是检测执行面停滞
其中已确认的现场问题有两个层次：
- mainland-controller-01 代理池可用性为 0
- worker 控制消息补偿链之前存在代码缺口，现已本地修复，待部署验证
worker 侧时光机异常仍是次级噪音，不应继续放大

下一步唯一主批次

唯一主批次维持为：J2-检测执行停滞收口批

本批次唯一目标：

先把控制消息补偿修复部署到线上 worker
再复查检测任务是否恢复推进
若仍停滞，再把剩余问题继续收紧到 controller 代理池可用数为 0
全程不做任何功能扩展

候选批次

Candidate J3

名称：检测执行恢复验证批

进入条件：

J2 明确根因后
代理或外部站点依赖恢复
再观察 domain_* 是否重新增长

Candidate J4

名称：上线签收证据批