# IMPLEMENTATION_STATUS

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

## 当前真实状态

阶段判断：

- 海外单脑接管能力：约 `97%`
- 发布闭环真实可用度：约 `65%~70%`
- 分布式检测真实执行能力：约 `80%~85%`
- 距离“可稳定上线并放心用后台发起检测”：约 `78%~82%`

## 21:17 最新校正

刚完成的 `mainland-worker-01` 正式 rollout 已给出最终根因：

- `job 211 / rollout 6 / release 7`
  - 发布包下载成功
  - release 解压成功
  - `current` 软链切换成功
  - 最终失败在服务重启：
    - `restart failed: domaincheck-worker`
    - `Failed to restart domaincheck-worker.service: Interactive authentication required.`

这说明：

- 当前 ReleaseHub 主链路本身已可推进到“切换 current”
- 真正未闭环的是 mainland node-agent 的 systemd 权限
- 只要 node-agent 仍以 `www` 运行，后续 `deploy.release / service.restart` 都会在 systemd 这一跳失败

已完成的代码侧修正：

- `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`

因此当前真实上线完成度需要再补一句校正：

- 发布闭环真实可用度：
  - 不是“发布包模型还没修”
  - 而是“node-agent 权限模型还差最后一次现网切换”

## 21:25 最新进展

worker 侧的现网切换已经完成验证成功：

- `mainland-worker-01`
  - 已把 `domaincheck-node-agent` 切为 `root`
  - 随后重新发起：
    - `rollout_id = 7`
    - `job_id = 214`
  - 最终结果：
    - `job 214 = success`
    - `rollout 7 = completed`

正式成功证据：

- `agent_completed`
  - `summary_text = release deployed`
- `restart_results[domaincheck-worker].returncode = 0`
- `health_check.ok = true`
- `systemd ExecStart` 已对齐：
  - `/opt/domaincheck/current/domainCheck/detect_worker.py`

因此当前关于发布闭环的真实判断应更新为：

- worker 发布闭环：
  - 已从“卡在 systemd restart 权限”推进到“真实成功”
- 当前剩余风险不再在 worker
- 当前剩余预防项在 controller：
  - `domaincheck-node-agent` 也应同步切为 `root`

## 顶部校正

今天晚上的最新结论，需要覆盖前面一部分偏乐观判断：

- 最新发布包问题已经定位并修复：
  - 之前发布包漏掉了 `domainCheck/`
  - 现在最新签收包 `domaincheck_release_20260419_205437` 已经包含 `domainCheck/`
- 但对 `mainland-worker-01` 的正式发布验证证明：
  - 线上 mainland 节点目前还不满足现有 ReleaseHub 发布模型
- 已确认的真实阻塞有两个：
  - `deploy.release` 在 `mainland-worker-01` 上会因为
    - `Permission denied: /opt/domaincheck/downloads`
    - 而直接失败
  - mainland 两台节点当前 `domaincheck-worker` 的 `ExecStart` 都直接指向：
    - `/opt/domaincheck/domainCheck/detect_worker.py`
    - 而不是 `/opt/domaincheck/current/domainCheck/detect_worker.py`

这两个事实组合起来说明：

- 当前发布链虽然在控制面上已经成型
- 但 mainland 线上节点的安装形态还是旧模式
- 所以当前不能再把“已能稳定 rollout 新版本”算进上线完成度

## 今晚新增硬证据

- `mainland-worker-01`
  - `job 204 / rollout 5` 已正式失败回写
  - 失败原因已收口为：
    - `install_root not writable: /opt/domaincheck/downloads`
  - 只读核验得到的实际服务状态仍是旧进程：
    - `Active since Sun 2026-04-19 18:18:50 CST`
    - `Main PID = 635924`
    - `CPU = 18.994s`
  - 说明 worker 当前并没有切到新包，也没有形成可信的新吞吐样本
- `mainland-controller-01`
  - 当前 `domaincheck-worker` 虽然在高负载运行
  - 但服务启动路径同样是：
    - `/opt/domaincheck/domainCheck/detect_worker.py`
  - 说明 controller 也没有对齐 `current` 软链发布模型

## 本轮代码侧新增收口

- 已补齐发布包构建：
  - `package_domain_release.sh`
  - `verify_domain_release.sh`
  - `package_domain_release.ps1`
  - `verify_domain_release.ps1`
  - 现在发布包会包含 `domainCheck/`
- 已补齐发布执行器的失败可观测性：
  - `domain-api/app/services/ops_release_executor_core.py`
  - 现在会在发布目录不可写时显式返回失败结果
  - 同时补充 `ExecStart` 与 `current` 软链的对齐观测
- 已补齐 node-agent 的兜底失败回写：
  - `domain-api/app/node_agent.py`
  - 避免以后再出现任务已经炸掉但控制面一直卡在 `running`

## 本轮最新结论

新增结论：

- 检测页观察面已完成一轮线上收口：
  - `任务日志控制台` 已移到事件表上方
  - `检测事件流` 已改成独立滚动区
  - 已在真实线上静态目录重建生产包并通过本机 `3201` 端口验证
  - 当前如果用户仍看到旧布局，优先判断为浏览器缓存而不是部署未生效
- 代理链已完成策略切换：
  - worker 启动后会主动刷新代理池
  - 配置更新后也会主动刷新代理池
  - 后台已能区分：
    - `等待首刷`
    - `proxy_validation_zero`
    - `直入池`
  - 当前本机最新真实结果是：
    - 原始代理 `270`
    - 预验证 `0`
    - 直入池 `270`
  - 说明当前问题已经从“代理校验过严导致池为空”切换为“真实任务内动态淘汰失效代理”

- `mainland-controller-01`
  - 已确认解除“代理不足即同步刷新、反向压死并发”的旧限制
  - 海外后台当前已能看到：
    - `active_threads = 99~100`
    - `max_threads = 100`
  - 说明 controller 的 `100` 并发已经真实生效
- `mainland-worker-01`
  - 已重新部署最新版 `detect_worker.py`
  - 已重新接收新的 `sync-pull` 批次并重进检测：
    - `开始执行域名检测任务`
    - `开始检测，刷新代理池`
    - `代理池刷新完成，共 23 个可用代理`
    - `开始创建线程，当前批次域名数: 400，最大线程数: 50`
  - 当前 worker 进程本机线程量已到：
    - `152` 个 OS 线程
  - 说明它并不是没启动，而是已经进入新批次执行
- 当前剩余偏差：
  - overseas 后台对 `mainland-worker-01.active_threads/current_load` 的显示仍偏低
  - 这已经从“真实执行问题”收敛为“运行态上报 / 显示口径问题”

这一轮不是只修了显示问题，而是把“大陆节点真实执行 + worker 日志回传”一起补齐了。

当前最新结论：

- controller 的 `pull_tasks -> 本地队列` 断点已经修通
- 两台大陆 worker 都已经进入真实镜像队列执行
- `mainland-worker-01` 的 `worker_log` 已开始直接回灌 overseas `detect_debug_events`
- `runtime_projection` 权限问题已经修复，后台运行态同步恢复
- `/api/v1/ops/nodes` 已能证明 controller 的高并发真实生效
- 当前剩余问题已经收敛为：
  - `mainland-worker-01` 运行态显示口径仍需继续对齐
  - 检测页主计数口径是否完全跟上
  - 结果统计回推是否持续稳定

## 当前证据拆分

### 1. 代码闭环

已经完成：

- `sync_push_service.ingest_detect_task_projection`
  - 不再只导入 `domains`
  - 已改为同时创建本地 `detect_jobs`
  - 已改为同时创建本地 `detect_job_items`
  - 已把 `target_job_id / target_job_code / queued_count / worker_start_ok` 回写到同步结果
- `sync_agent`
  - controller 现在会在每轮 `pull_tasks` 后自动唤起本地 worker
- `detect_worker._set_active_cycle_context`
  - 已兼容 `sync-pull` 控制消息
  - 不再只读取 `job_id / job_code`
  - 现在会回退读取 `target_job_id / target_job_code`
- 运行态同步链
  - controller `runtime/detect_runs.json` 权限已修正为 `www:www`
  - `runtime_projection` 已恢复成功推送

本地代码验证已通过：

- `python -m py_compile domain-api/app/services/sync_push_service.py`
- `python -m py_compile domain-api/app/services/runtime_control_service.py`
- `python -m py_compile domain-api/app/sync_agent.py`
- `python -m py_compile domainCheck/detect_worker.py`

### 2. 接管 / 外部条件闭环

已经完成：

- `remote_access_ready = 3/3`
- `ssh_ready = 2`
- 大陆 controller / worker 都可远程运维
- controller `domaincheck-sync-agent` 在线
- mainland 两台 `domaincheck-node-agent` 在线

当前仍依赖你额外输入的部分：

- 暂无新的 SSH / 接管前置输入缺口
- 如果页面仍显示旧状态，最多只需要你浏览器强刷确认，不需要再补 SSH 信息

### 2.1 前端部署闭环

已经完成：

- 在线静态根目录确认：
  - `/www/wwwroot/getDomain/domain-web/dist`
- 在线 Nginx 配置确认：
  - `/www/server/panel/vhost/nginx/domaincheck_3201.conf`
  - `/www/server/panel/vhost/nginx/domaincheck_152.53.37.118.conf`
- 生产包重建确认：
  - `vite build` 成功
- 线上资源确认：
  - `DetectView-B9S1WMRT.js`
  - `DetectView-BFxMNRNR.css`

说明：

- 检测页布局调整不是只停留在源码
- 已经进入线上可访问静态产物

### 2.2 代理运行态闭环

已经完成：

- worker 启动即触发代理池首刷
- 配置变更后自动补刷
- API 状态页已能准确显示：
  - `proxy_not_refreshed_yet`
  - `proxy_validation_zero`
  - `宽松入池`

当前最新证据：

- `proxy_last_refresh_status = 直入池 270 个（跳过预验证）`
- `proxy_last_refresh_total_items = 270`
- `proxy_last_validated_count = 0`
- `proxy_last_available_count = 270`

说明：

- 代理配置本身已成功下发
- 代理源接口本身也能返回大量原始代理
- 当前不再把“预验证是否通过”作为入池门槛
- 现在改为让真实检测来完成失效代理淘汰

### 3. 检测执行闭环

这一块现在已经从“怀疑恢复”进入“确认恢复”：

- `mainland-controller-01`
  - 已出现：
    - `从任务队列获取到 800 个需要检测的域名`
    - `最大线程数: 100`
    - `当前实际线程数量: 1/100 ... 6/100`
- `mainland-worker-01`
  - 已出现：
    - `从任务队列获取到 400 个需要检测的域名`
    - `开始创建线程，当前批次域名数: 400，最大线程数: 50`
    - `当前实际线程数量: 1/50 ... 3/50`
    - `开始检测域名: 0-demagogo.com`
    - `开始检测域名: 00123321.com`
    - `开始检测域名: 001dm.com`

这说明：

- `100/50` 已不是“配置已写入但没生效”
- 它已经进入真实任务消费
- worker 的远端日志也已经跟着真实执行一起回传

### 4. 海外后台可视证据

`/api/v1/ops/nodes` 当前已显示：

- `summary.remote_access_ready = 3`
- `summary.participating = 3`
- `summary.dispatch_active = 1`

并且大陆两台都已经被判定为真实参与者：

- `mainland-controller-01`
  - `agent_state = online_busy`
  - `participation_state = recent_throughput`
  - `processed_recent = 115`
  - `processed_per_minute = 7.67`
  - `detect_runtime.max_threads = 100`
- `mainland-worker-01`
  - `agent_state = online_busy`
  - `participation_state = recent_throughput`
  - `processed_recent = 632`
  - `processed_per_minute = 42.13`
  - `detect_runtime.max_threads = 50`

这说明：

- 海外后台已经不只是看到“在线”
- 现在已经能看到大陆节点的实际吞吐

## 本轮新增硬证据

### 证据 1：controller 的镜像队列已经真正落库

`sync-agent` 现场日志已出现：

- `target_job_code = sync-overseas-7380`
- `queued_count = 200`
- `worker_start_ok = True`

并持续产生：

- `sync-overseas-7383`
- `sync-overseas-7386`
- `sync-overseas-7392`
- `sync-overseas-7417`

说明：

- 大陆 controller 现在不是只拉数据
- 而是在持续形成可执行批次

### 证据 2：两台大陆 worker 都已转入真实队列

现场日志已明确出现：

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

说明：

- 当前不是兼容旧链路假运行
- 是镜像队列真运行

### 证据 3：runtime_projection 已恢复成功

修复前：

- `refresh runtime_projection failed: [Errno 13] Permission denied`

修复后：

- 最新 `sync-agent` 日志已出现：
  - `sync_state = success`
  - `runtime_projection -> 投影推送成功`

说明：

- 后台运行态刷新和日志窗口不再被 controller 本地权限卡死

### 证据 4：`mainland-worker-01` 的 `worker_log` 已进入 overseas

`/api/v1/runtime/debug-events` 当前已能看到：

- `mainland-worker-01 -> 开始执行检测任务，来源: redis-control`
- `mainland-worker-01 -> 开始执行域名检测任务，正在加载配置`
- `mainland-worker-01 -> 开始检测，正在刷新代理池`
- `mainland-worker-01 -> 代理池刷新完成，共 7 个可用代理，来源链接 6 个，原始 265 个，验证 150 个`
- `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 的真实执行链已经进入 overseas 的日志视图
- “后台看不到大陆 worker 在干活”这一层已经闭合

## 当前口径说明

这里有一个非常关键的判断口径已经变化：

- 大陆节点当前执行的是“海外任务在大陆本地落镜像队列，再把运行态和结果同步回海外”
- 因此不能再只盯中央原生 `detect_job_items.claimed/running`
- 现在应该同时看：
  - `/api/v1/ops/nodes`
  - `processed_recent`
  - `processed_per_minute`
  - `detect_runtime.active_threads/max_threads`
  - 大陆 controller 本地 `sync-overseas-*` 队列

如果只看中央原生队列，会误判“大陆没有参与”。

## 当前已闭合的问题

已闭合：

- controller `pull_tasks` 只导入 domain、不导入本地队列
- 大陆 worker 长时间卡在旧检测会话导致忽略新启动指令
- controller `runtime_projection` 因文件属主错误无法推送
- 大陆两台“在线但不确定是否真实执行”的状态模糊

## 当前剩余问题

当前剩余问题已经缩成两个最小项：

- Detect 页面主计数 `pending/completed/running` 是否继续推进
- 结果统计回推是否稳定，而不只是日志链路先恢复

换句话说：

- 现在不是接管问题
- 不是链路不通问题
- 不是日志完全回不来问题
- 而是最后一层“主计数推进 + 结果统计收口”问题

## 当前是否可以继续跑检测测试

当前结论：

- 可以继续跑检测测试
- 而且现在已经具备“后台可观测 + 大陆真实参与”的条件

## 当前是否建议直接上线

当前结论：

- 已接近可上线状态
- 但我仍建议把它视为“准上线收口态”，不是最终完全签收态

原因：

- 主执行链已经恢复
- 但还需要再确认 1 到 2 个同步周期内页面口径与吞吐稳定性

## 当前优先级判断

最高优先级：

- `J2-检测执行收口批`

当前不应继续推进：

- 新控制面功能
- 新模块
- 新页面
- 发布动作
- 与检测执行收口无关的工作

## 完成下一轮后的预期

如果下一轮确认：

- Detect 页面主计数已跟上
- 日志窗口持续刷新
- `detect_result_projection` 持续推进
- `processed_recent / processed_per_minute` 持续增长

则整体可上线程度预计可提升到：

- `96%~98%`

在那之前，当前口径应保持保守。