Fix worker control fallback for running detect workers
This commit is contained in:
Your Name
@@ -1,99 +1,248 @@
|
||||
# TASK_BOARD
|
||||
|
||||
更新时间：2026-04-19 03:00 CST
|
||||
更新时间：2026-04-19 03:38 CST
|
||||
|
||||
## 当前主批次
|
||||
|
||||
唯一主批次：`J1-大陆逐条结果同步前置批`
|
||||
唯一主批次：`J2-检测执行停滞收口批`
|
||||
|
||||
目标：
|
||||
|
||||
- 不进入新页面
|
||||
- 不扩展控制面
|
||||
- 只解决 item 级统一前的唯一前置缺口：
|
||||
- 大陆节点逐条检测事件进入中央
|
||||
- 不新增发布动作
|
||||
- 只收口当前唯一真实阻塞：
|
||||
- 节点已接管
|
||||
- 同步已打通
|
||||
- 但检测执行没有继续产出新结果
|
||||
|
||||
## 本轮最新状态
|
||||
|
||||
本轮在只读取证基础上，已经补了一处最小代码修复，但还没有完成线上节点拉代码后的运行验证。
|
||||
|
||||
### 已完成的最小修复
|
||||
|
||||
- `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` 日志采样：
|
||||
|
||||
- `runtime_ingest` 仍在持续刷新
|
||||
- `detect_result_ingest` 仍未刷新
|
||||
- `detect_run_events` 里仍没有 mainland `domain_*`
|
||||
- 活跃任务仍是 `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：mainland 同步链仍然活着
|
||||
### 证据 1：接管与同步已通
|
||||
|
||||
中央最新记录显示：
|
||||
当前中央状态：
|
||||
|
||||
- `runtime_ingest.updated_at`
|
||||
- 已刷新到 `2026-04-19 02:59:12`
|
||||
- `remote_access_ready = 3/3`
|
||||
- `log_sync_state = full_capture`
|
||||
- mainland controller 的 `domaincheck-sync-agent` 已在新进程上运行
|
||||
|
||||
说明：
|
||||
|
||||
- mainland controller 仍在向中央推运行时投影
|
||||
- 当前不是接管问题
|
||||
- 也不是日志回传问题
|
||||
- 更不是同步链完全断开
|
||||
|
||||
### 证据 2：mainland 逐条结果投影仍未开始刷新
|
||||
### 证据 2：检测任务当前没有继续出新结果
|
||||
|
||||
中央最新记录显示：
|
||||
连续 40 秒前后对比结果完全一致：
|
||||
|
||||
- `detect_result_ingest.updated_at`
|
||||
- 仍停留在 `2026-04-17 16:57:32`
|
||||
|
||||
而且当前最新 mainland `detect_result_ingest` 中：
|
||||
|
||||
- `job_code = None`
|
||||
- `latest_event_type = None`
|
||||
- `recent_domain_events = 0`
|
||||
- `JOB_PROGRESS = 2.1`
|
||||
- `items_completed = 21`
|
||||
- `items_running = 14`
|
||||
- `items_claimed = 34`
|
||||
- `items_pending = 931`
|
||||
|
||||
说明：
|
||||
|
||||
- mainland 还没有开始推送新版 `detect_result_projection`
|
||||
- 当前不是“页面慢一拍”
|
||||
- 而是执行面这段时间确实没有继续产出
|
||||
|
||||
### 证据 3：中央逐条事件仍为空
|
||||
### 证据 3：中央 mainland 逐条结果没有继续增长
|
||||
|
||||
当前中央查询结果：
|
||||
|
||||
- mainland `domain_started/domain_completed/domain_failed/domain_blacklisted`
|
||||
- `count = 0`
|
||||
- 仍为 `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 端没有真正跑到新版 `domaincheck-sync-agent`
|
||||
- 接管链路已基本完成
|
||||
- 同步链路已至少成功贯通一次
|
||||
- 当前主阻塞依旧是检测执行面停滞
|
||||
- 其中已确认的现场问题有两个层次：
|
||||
- `mainland-controller-01` 代理池可用性为 `0`
|
||||
- worker 控制消息补偿链之前存在代码缺口，现已本地修复，待部署验证
|
||||
- worker 侧时光机异常仍是次级噪音，不应继续放大
|
||||
|
||||
## 下一步唯一主批次
|
||||
|
||||
唯一主批次仍然是：`J1-大陆逐条结果同步前置批`
|
||||
唯一主批次维持为：`J2-检测执行停滞收口批`
|
||||
|
||||
本批次唯一目标：
|
||||
|
||||
- 让 mainland 拉最新代码并重启 `domaincheck-sync-agent`
|
||||
- 然后在中央确认出现：
|
||||
- `detect_result_ingest.payload.projection.recent_domain_events`
|
||||
- mainland `domain_*`
|
||||
- 先把控制消息补偿修复部署到线上 worker
|
||||
- 再复查检测任务是否恢复推进
|
||||
- 若仍停滞，再把剩余问题继续收紧到 controller 代理池可用数为 0
|
||||
- 全程不做任何功能扩展
|
||||
|
||||
## 候选批次
|
||||
|
||||
### Candidate J2
|
||||
|
||||
名称：item 级回写最小落地批
|
||||
|
||||
进入条件：
|
||||
|
||||
- `J1` 完成后，中央已经能收到大陆逐条结果
|
||||
|
||||
### Candidate J3
|
||||
|
||||
名称：raw/effective 运营文案收口批
|
||||
名称：检测执行恢复验证批
|
||||
|
||||
进入条件：
|
||||
|
||||
- 如果用户只想先补页面文案
|
||||
- `J2` 明确根因后
|
||||
- 代理或外部站点依赖恢复
|
||||
- 再观察 `domain_*` 是否重新增长
|
||||
|
||||
### Candidate J4
|
||||
|
||||
名称：上线签收证据批
|
||||
|
||||
进入条件：
|
||||
|
||||
- `J3` 确认检测重新持续产出
|
||||
- `go-live-summary` 只剩历史 attention
|
||||
|
||||
## 暂停项
|
||||
|
||||
@@ -103,14 +252,22 @@
|
||||
- 新模块
|
||||
- 控制面增强
|
||||
- 发布动作
|
||||
- 与大陆逐条结果同步无关的工作
|
||||
- 与检测执行停滞无关的工作
|
||||
|
||||
## 下一轮唯一动作
|
||||
|
||||
下一轮唯一应该继续做的事情：
|
||||
|
||||
- 在 mainland 节点执行：
|
||||
- `git pull`
|
||||
- `systemctl restart domaincheck-sync-agent`
|
||||
- `systemctl status domaincheck-sync-agent --no-pager -l`
|
||||
- `journalctl -u domaincheck-sync-agent -n 80 --no-pager`
|
||||
- 只做最小部署与运行态收口：
|
||||
- 大陆节点拉取最新代码
|
||||
- 重启 `domaincheck-worker`
|
||||
- 复查 `/api/v1/detect/job/active`
|
||||
- 复查 `/api/v1/runtime/sync-summary`
|
||||
- 复查 controller / worker `scene-log`
|
||||
- 必要时追加 `domaincheck-worker` 运行日志取证
|
||||
- 唯一判断问题是：
|
||||
- 修复部署后，任务是否重新推进
|
||||
- 若仍不推进，是否只剩 controller 代理池 `0 available` 这一条主阻塞
|
||||
- 是否仍是 `近窗吞吐 0`
|
||||
- 是否仍是 `controller 可用代理数 0`
|
||||
- 代理恢复后 `domain_*` 是否重新增长
|
||||
|
||||
Reference in New Issue
Block a user