# TASK_BOARD

更新时间：2026-04-19 21:25 CST

## 2026-04-20 主线切换说明

从这一刻开始，当前工作重心正式切回：

- 先跑通主任务流程
- 先推进 7 个大任务的测试与验收
- 并发、代理、DB 往返、展示层等细节优化先封存，不再抢主线

细节优化不删除，统一视为 backlog：

- worker pool 持续补位
- claimed 回弹压缩
- 高频 DB 更新继续合并
- 代理失败链和等待窗口继续压缩
- 运营视角页面继续细化

这些后续继续做，但不再打断主任务验收顺序。

当前主口径：

1. 大任务 1 真实验收闭环
2. 大任务 2 controller 编排闭环
3. 大任务 3 统一结果状态机闭环
4. 大任务 4 本地控制状态 + syncer/finalizer 闭环
5. 大任务 5 固定 worker pool 落地
6. 大任务 6 时光机一期接入
7. 大任务 7 运营视角面板闭环

## 21:17 最新补充

刚刚这轮真实 rollout 已经把 mainland worker 的最后一层阻塞拿实：

- `mainland-worker-01`
  - `release_id = 7`
  - `rollout_id = 6`
  - `job_id = 211`
- 发布链路并不是卡在下载或解压：
  - 发布包 `domaincheck_release_20260419_205437` 已下载到 `/opt/domaincheck/downloads`
  - release 已解压到 `/opt/domaincheck/releases/domaincheck_release_20260419_205437`
  - `/opt/domaincheck/current` 已切到新 release
- 最终失败点已经明确：
  - `restart failed: domaincheck-worker`
  - systemd 原因：
    - `Interactive authentication required`
- 这说明当前 mainland 节点的 `domaincheck-node-agent` 虽然能写发布目录，但因为以 `www` 身份运行，无法执行：
  - `systemctl restart domaincheck-worker`

当前新的唯一主阻塞已经进一步收敛为：

- node-agent systemd 运行身份不对
- 需要把 `domaincheck-node-agent` 改成 `root` 运行，发布链最后一跳才能闭环

本轮已在仓库内同步修正：

- `domain-api/deploy/systemd/domain-node-agent.service`
  - `User=root`
  - `Group=root`
- `domain-api/deploy/multi-region/fix_mainland_release_base.sh`
  - node-agent drop-in 现在也会显式写入：
    - `User=root`
    - `Group=root`

## 21:25 worker rollout 收口

`mainland-worker-01` 已完成新一轮正式 rollout 收口成功：

- `release_id = 7`
- `rollout_id = 7`
- `job_id = 214`

结果确认：

- `job 214 = success`
- `rollout 7 = completed`
- `mainland-worker-01` 已恢复为：
  - `agent_state = online_busy`
  - 最近心跳恢复正常

控制面完成证据：

- `agent_completed`
  - `summary_text = release deployed`
- `restart_results`
  - `domaincheck-worker.returncode = 0`
- `health_check.ok = true`
- `execstart_alignment.mismatched_services = []`

这说明 worker 当前已经真正完成：

- 新包下载
- release 解压
- `current` 切换
- `domaincheck-worker` 重启
- 健康检查通过

当前关于 mainland rollout 的唯一剩余预防项变成：

- `mainland-controller-01` 也应该同步把 `domaincheck-node-agent` 切到 `root`
- 否则后续 controller 自身执行 `deploy.release / service.restart` 时还会踩到同类 systemd 权限问题

## 顶部校正

今天晚上的最新排查已经把当前主阻塞重新定性，之前“大陆两台已经完全进入统一新镜像执行”的判断需要收紧。

当前新增硬结论：

- 最新正式发布包已经重打并签收通过：
  - `domaincheck_release_20260419_205437`
  - 发布包现在已经确实包含 `domainCheck/`
- 对 `mainland-worker-01` 发起正式 smart rollout 后，真实失败原因已经拿到：
  - `job 204 / rollout 5`
  - 本次失败对应的正式 Release 版本仍是：
    - `domaincheck_release_20260419_203933`
  - 失败原因：
    - `Permission denied: /opt/domaincheck/downloads`
  - 该失败已通过正式 agent complete 回写，后台不再是假 `running`
- `mainland-worker-01` 当前运行中的 `domaincheck-worker` 仍是旧进程：
  - `Main PID = 635924`
  - `Active since = 2026-04-19 18:18:50 CST`
  - `CPU = 18.994s`
  - 说明它不是高吞吐新进程，而是老进程长期挂着
- `mainland-controller-01` 当前运行中的 `domaincheck-worker` 虽然活跃，但服务启动路径同样是：
  - `/opt/domaincheck/domainCheck/detect_worker.py`
- 两台 mainland 节点当前 `domaincheck-worker` 的 systemd 启动路径都不是：
  - `/opt/domaincheck/current/domainCheck/detect_worker.py`

这意味着：

- 当前 ReleaseHub 的 `current -> release_version` 切换模型，与线上 mainland 节点的实际服务启动路径不一致
- 即使发布包和签收链已经修好，线上节点也还没有具备“按当前发布模型热切版本”的条件
- 当前唯一主阻塞已经从“并发参数是否下发”切换成：
  - mainland 节点发布权限/目录模型不匹配
  - mainland 节点服务启动路径与发布模型不匹配

## 当前主批次

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

目标：

- 不进入新页面
- 不扩展控制面
- 不新增发布动作
- 只收口三件已经缩小到运行面的事情：
  - 大陆节点必须真正进入统一镜像队列，而不是停留在兼容旧链路
  - 后台必须能看到大陆节点的实时运行态与日志
  - `100/50` 并发配置要从“已下发”推进到“真实有参与吞吐”

## 本轮最新状态

### 20:53 最新阻塞结论

- `mainland-worker-01` smart rollout 已真实失败，不再继续误判为执行中
- 失败证据：
  - node-agent 日志：
    - `2026-04-19 20:40:15 [node-agent] loop error: [Errno 13] Permission denied: '/opt/domaincheck/downloads'`
  - 发布任务：
    - `job 204 = failed`
  - 发布批次：
    - `rollout 5 = failed`
- 当前不应该继续把精力放在前端展示或并发口径微调上
- 当前必须先收口：
  - mainland 节点 `deploy.release` 所需目录权限
  - mainland 节点 systemd `ExecStart` 与 `/opt/domaincheck/current` 的一致性

这轮已经完成从“控制链打通”到“真实执行恢复 + worker 日志回传恢复”的关键跨越。

### 本轮前端已上线校验

- 检测页 `任务日志控制台` 已调整到事件列表上方
- `检测事件流` 已改成独立滚动区：
  - 表格 `max-height = 320`
  - 避免事件越积越多把整个页面继续向下撑长
- 已在线上实际静态目录重新构建：
  - `/www/wwwroot/getDomain/domain-web/dist`
- 已确认线上 Nginx 指向该目录：
  - `domaincheck_3201.conf`
  - `domaincheck_152.53.37.118.conf`
- 已通过 `http://127.0.0.1:3201/` 返回 `200` 且加载新资源：
  - `DetectView-B9S1WMRT.js`
  - `DetectView-BFxMNRNR.css`

### 本轮代理链已收口

- 已修复 worker 在“代理配置已下发但尚未开始检测”时长期停留 `未刷新` 的问题
- `domaincheck-worker` 现在会在以下时机主动触发代理池刷新：
  - worker 启动后
  - `proxy_config / thread_count / node_thread_counts / runtime_settings` 更新后
- 当前后台状态已不再误报“未刷新”
- 代理策略已切到：
  - 只去掉过期 / 非法代理
  - 跳过预验证
  - 直接入池执行
  - 真实失败后立即淘汰并补刷
- 最新实测结果已经明确：
  - 原始代理 `270` 个
  - 预验证 `0` 个
  - 当前可用代理 `270` 个
  - 最近状态：
    - `proxy_last_refresh_status = 直入池 270 个（跳过预验证）`
    - `available_proxy_count = 270`

### 本轮已完成

- `sync_push_service`
  - 已修复 `detect_task_ingest` 只落 `domains`、不落本地 `detect_jobs/detect_job_items` 的缺口
  - controller 现在会为拉回来的海外批次持续创建本地镜像任务：
    - `sync-overseas-7380`
    - `sync-overseas-7383`
    - `sync-overseas-7392`
    - 持续增长中
- `mainland-controller-01`
  - 已重启 `domaincheck-worker`
  - 已明确进入真实队列：
    - `从任务队列获取到 800 个需要检测的域名`
    - `最大线程数: 100`
    - `当前实际线程数量: 1/100 ... 6/100`
- `mainland-worker-01`
  - 已修复 `sync-pull` 控制消息上下文绑定缺口：
    - `detect_worker._set_active_cycle_context` 现在会读取
      - `target_job_id`
      - `target_job_code`
  - 已重启 `domaincheck-worker`
  - 已明确进入真实队列：
    - `从任务队列获取到 400 个需要检测的域名`
    - `最大线程数: 50`
    - `当前实际线程数量: 1/50 ... 3/50`
  - 已明确把运行日志回传到 overseas：
    - `开始执行检测任务，来源: redis-control`
    - `开始执行域名检测任务，正在加载配置`
    - `开始检测，正在刷新代理池`
    - `开始创建线程，当前批次域名数: 400，最大线程数: 50`
    - `当前实际线程数量: 1/50`
    - `当前实际线程数量: 2/50`
    - `当前实际线程数量: 3/50`
- `runtime_projection`
  - 已定位 controller `domain-api/runtime/detect_runs.json` 权限错误
  - 已把 `runtime` 目录和 `detect_runs.json` 改回 `www:www`
  - `domaincheck-sync-agent` 最新日志已从
    - `partial_success`
  - 变成：
    - `sync_state = success`
    - `runtime_projection -> 投影推送成功`
- 海外控制面 `/api/v1/ops/nodes`
  - 现已明确看到三台节点都在参与
  - `remote_access_ready = 3`
  - `participating = 3`
  - `mainland-controller-01.is_current_participant = true`
  - `mainland-worker-01.is_current_participant = true`

### 当前最关键的新证据

- `mainland-controller-01`
  - `processed_recent = 115`
  - `processed_per_minute = 7.67`
  - `detect_runtime.max_threads = 100`
- `mainland-worker-01`
  - `processed_recent = 632`
  - `processed_per_minute = 42.13`
  - `detect_runtime.max_threads = 50`
- `overseas-control-01`
  - 仍在执行中央原生队列
- 当前判断：
  - 大陆节点已经不是“纸面在线”
  - 已经是真实参与检测执行

## 当前主判断

### 本轮新增结论

- `mainland-controller-01`
  - 已修复“代理数量不足反向限制并发”的热路径问题
  - 当前海外后台已稳定看到：
    - `active_threads ~= 99~100`
    - `max_threads = 100`
  - 说明 `100` 并发不再只是配置已下发，而是已进入真实运行态
- `mainland-worker-01`
  - 已重新部署同版 `detect_worker.py`
  - 已重新接收到新的 `sync-pull` 批次：
    - `source_record_id = 7679`
    - `target_job_code = sync-overseas-7679`
  - 已完成代理抽样校验并进入：
    - `开始创建线程，当前批次域名数: 400，最大线程数: 50`
  - 当前剩余问题已经缩成：
    - worker 本机已启动新批次并创建线程
    - 但海外后台对 `mainland-worker-01.active_threads` 的显示仍偏低，和本机进程线程量不完全一致

### 当前唯一剩余收口点

- 不再是 controller 并发限制问题
- 当前唯一剩余收口点变成：
  - `mainland-worker-01` 的运行态上报口径仍需继续和真实执行量对齐
  - 以及检测主计数 `pending/completed/running` 继续推进

### 已经收口的部分

- 大陆节点不再停留在 `pending_bootstrap`
- Agent + SSH 接管已经完成
- `sync-agent pull_tasks` 已经真正生成本地镜像队列
- 两台大陆 worker 已经真正吃到 `detect_job_items`
- 后台运行态同步链已经恢复

### 当前剩余问题

- Detect 页面日志窗口已经不再是单节点
- `/api/v1/detect/status` 已出现：
  - `remote_log_node_count = 2`
  - `remote_log_nodes = ["mainland-controller-01", "mainland-worker-01"]`
- 当前剩余问题缩成一个最小点：
  - 检测页主计数 `pending/completed/running` 还没有跟着这轮大陆执行立即推进
- 前端布局问题已收口，后续不再停留在“页面结构挡住观察”
- 代理链当前也已收口到真实口径，不再停留在“配置有了但没刷新”
- 下一步应继续观察这 `270` 个直入池代理在真实检测里的淘汰速度与吞吐提升
- 现在更应该同时看：
  - `/api/v1/detect/status`
  - `/api/v1/runtime/debug-events`
  - `/api/v1/ops/nodes`
  - worker `current actual threads` 日志

## 下一步唯一主批次

唯一主批次保持为：`J2-检测执行收口批`

下一步只做：

- 继续观察 Detect 页面主计数是否跟上最新运行态
- 继续确认 `detect_result_projection` / 结果统计回推是否稳定推进
- 继续收口 `mainland-worker-01` 的运行态上报，使后台显示与本机真实线程量一致
- 若仍有显示偏差，只修统计/上报口径，不新扩功能

## 候选批次

### Candidate J3

名称：结果计数收口批

进入条件：

- 节点已经真实执行
- 日志窗口已经恢复
- 但 Detect 页面主计数仍不前进

只做：

- 复核 `detect_result_projection`
- 复核结果统计回推
- 不改控制面结构

### Candidate J4

名称：吞吐稳定性观察批

进入条件：

- 页面口径已恢复
- 继续确认大陆两节点吞吐是否稳定，不再回落

只做：

- 继续观察 `processed_recent`
- 继续观察代理池质量
- 继续观察 `active_threads/max_threads`

## 暂停项

以下任务现在不应继续推进：

- 新页面
- 新模块
- 新发布动作
- 新专题文档
- 与检测执行收口无关的控制面增强

## 关键证据

### 证据 1：镜像队列已经落地

controller `sync-agent` 最新 `task pull tick` 已出现：

- `target_job_id`
- `target_job_code`
- `queued_count = 200`
- `worker_start_ok = True`

说明：

- controller 现在不是只同步域名
- 而是在本地持续创建可执行队列

### 证据 2：大陆 worker 已进入真实队列

现场日志已经明确出现：

- `mainland-controller-01 -> 从任务队列获取到 800 个需要检测的域名`
- `mainland-worker-01 -> 从任务队列获取到 400 个需要检测的域名`

说明：

- “并发没起来”的主要根因已经修正
- 它们不是在跑旧兼容链路

### 证据 3：运行态同步已恢复

controller `sync-agent` 最新日志已经出现：

- `sync_state = success`
- `runtime_projection -> 投影推送成功`

说明：

- 后台运行态/日志窗口链路已经不再被权限错误卡死

### 证据 4：海外 `/ops/nodes` 已把大陆节点判定为真实参与者

当前海外控制面已经显示：

- `mainland-controller-01`
  - `online_busy`
  - `is_current_participant = true`
  - `processed_recent = 115`
- `mainland-worker-01`
  - `online_busy`
  - `is_current_participant = true`
  - `processed_recent = 632`

说明：

- 现在大陆两台都已进入真实参与态
- 下一步不再是接管问题，而是页面口径与吞吐稳定性问题

### 证据 5：Detect 页面远端日志已恢复双节点

当前 `/api/v1/detect/status` 已显示：

- `remote_log_node_count = 2`
- `remote_log_nodes = ["mainland-controller-01", "mainland-worker-01"]`

最近日志样本已出现：

- `mainland-worker-01 -> 从任务队列获取到 400 个需要检测的域名`
- `mainland-worker-01 -> 开始创建线程，当前批次域名数: 400，最大线程数: 50`
- `mainland-worker-01 -> 当前实际线程数量: 1/50`
- `mainland-worker-01 -> 当前实际线程数量: 2/50`
- `mainland-worker-01 -> 当前实际线程数量: 3/50`

说明：

- worker 不再是“只在节点本地运行、页面看不到”
- 检测页日志链已经真正接上 mainland worker

### 证据 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

名称：上线签收证据批

进入条件：

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

## 暂停项

继续暂停：

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

## 下一轮唯一动作

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

- 只做 controller 代理收口：
  - 继续复查 controller `domaincheck-worker` 日志
  - 观察是否从 `当前无可用代理` 转为有可用代理
  - 继续复查 `/api/v1/detect/job/active`
  - 继续复查 `/api/v1/runtime/sync-summary`
  - 继续复查 recent domain events 是否出现 controller / 新 completed
- 唯一判断问题是：
  - controller 代理池恢复后，completed 是否开始继续增长
  - 是否仍是 `近窗吞吐 0`
  - 是否仍是 `controller 可用代理数 0`
  - 代理恢复后 `domain_*` 是否重新增长