274 lines
7.8 KiB
Markdown
274 lines
7.8 KiB
Markdown
# 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_*` 是否重新增长
|