# 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

名称：上线签收证据批

进入条件：

- `J3` 确认检测重新持续产出
- `go-live-summary` 只剩历史 attention

## 暂停项

继续暂停：

- 新页面
- 新模块
- 控制面增强
- 发布动作
- 与检测执行停滞无关的工作

## 下一轮唯一动作

下一轮唯一应该继续做的事情：

- 只做最小部署与运行态收口：
  - 大陆节点拉取最新代码
  - 重启 `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_*` 是否重新增长