admin/getDomain

Fork 0

Files

Your Name e0406b5d0e Update runtime handoff after mainland deploy validation

2026-04-19 03:43:19 +08:00

8.0 KiB

Raw Blame History

TASK_BOARD

更新时间：2026-04-19 03:41 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

已完成的线上验证

mainland-worker-01
- 已拉到 main 最新提交 c33f4f1
- 已重启 domaincheck-worker
- 启动后明确出现：
  - 发现待执行 Worker 控制指令
  - 已接受检测启动指令
  - 开始执行远程检测任务
mainland-controller-01
- 已拉到 main 最新提交 c33f4f1
- 已重启 domaincheck-worker
- 发现运行环境漂移：
  - /etc/default/domaincheck-worker 中 REDIS_PASSWORD 为空
- 已最小修正该节点运行环境后再次重启
- 修正后明确出现：
  - Redis 连接成功: 127.0.0.1:6379
  - 已接受检测启动指令
  - 开始执行远程检测任务

本轮仍未完成的事情

中央 items_completed 仍未在短观察窗口内继续增长
mainland-controller-01 仍然持续报：
- 代理已启用，但当前无可用代理
因此当前剩余阻塞已经进一步收紧到：
- controller 现场代理池没有可用代理

本轮最新复查结果

本轮在完成修复部署后，中央与节点现场出现了新的运行证据：

活跃任务仍是 detect-20260417170546-96023e
mainland-worker-01 最新事件时间已经从旧窗口推进到：
- 2026-04-19 16:37:00
runtime/sync-summary 最新记录已继续增长到：
- id = 5491
- created_at = 2026-04-19 03:40:45
说明中央已经重新收到新的运行侧同步流量
但短窗口内主进度仍未松动：
- completed = 21
- running = 14
- claimed = 34
- pending = 931
controller 现场最新日志已收紧为：
- 代理已启用，但当前无可用代理

关键证据

证据 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-worker-01 已从 pending 指令恢复执行
mainland-controller-01 在修正 Redis 环境后，也已重新接受并执行 start_detection

当前结论

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

接管链路已基本完成
同步链路已至少成功贯通一次
当前主阻塞仍是检测执行面没有恢复到“持续产出”
但代码级控制链缺口已经闭合
当前唯一剩余现场阻塞可以收紧为：
- mainland-controller-01 代理池可用性为 0
worker 侧时光机异常仍是次级噪音，不应继续放大

下一步唯一主批次

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

本批次唯一目标：

保持当前不扩功能
只围绕 controller 代理池可用性为 0 做收口
继续观察修正后的 controller 是否开始产出 domain 级结果
若仍无结果增长，则只给出代理层最小补救路径

候选批次

Candidate J3

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

进入条件：

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

Candidate J4

名称：上线签收证据批