# R7 任务报告

## 结论

- 近期页面记录中，外部客户可确认的失败为 `xiaoyang@test.com` 请求 `10766195-ee99-4c84-8bbc-e21df23e141f`：`/v1/messages/count_tokens` 在账号 `https://sub2.pokexiao.com pro 0.05` 等待 60 秒后因 transport `context canceled` 返回 502；该 handler 没有进入 Sub2API failover 事件链，现有 runtime 模板无法修复，后续若要求彻底解决需官方源码增加 count_tokens failover。
- 自用池请求 `24cc5f1b-e1e8-4ca1-b73d-b4735e55b3d4` 的真实 upstream 状态为 522，响应为 `Upstream request failed`，账号 `https://sub.yjxm1221.top pro 0.06` 原规则不含 522，未触发临时不可调度。
- owning YAML 的 `codex-upstream-failover` 通用模板新增 `522 + upstream request failed`，冷却 1 分钟；未修改 Sub2API 源码、版本、优先级、容量或外部哨兵。

## 应用与对账

- dry-run 使用 configured-policy 自动选集，精确排除 `lyon9801 0.0`；选中 9 个 API-key 账号，唯一差异为规则数 `8 -> 9` 和状态码新增 522。
- confirm 结果：selected=9、writeSucceeded=9、writeFailed=0、reconciled=9、mismatched=0。
- 账号 `https://sub.yjxm1221.top pro 0.06` 回读为 `RULES=9`，状态码 `400,429,500,502,503,504,522,524,529`。

## 诊断纠正

- 内部 `monitor` 的请求 `643ab721-65ae-4f21-a119-2a5e81abb31f` 和 `78b55ec3-406d-4429-ac1e-8118094a8090` 虽有 upstream 502，但客户最终均为 499，前者已发生多次 failover；不应计为客户可见错误或账号扣分。
- `lyon9801` 请求 `7ae72409-e5d1-4c14-8963-d63179b4cc35` 在 569ms 因 `context canceled` 返回 499，不是上游故障。
- upstream 524 样本 `afffce5c-9eb0-4226-b765-85312ca31af0` 最终为客户 499，并记录 `failover_aborted_client_disconnected`；不能把 upstream phase 524 直接计为客户穿透。
- 修复后 15 分钟窗口中，自用池客户错误为 0；盈利池唯一聚合错误 `430c8303-f7e0-4a25-bf9c-e988a5805660` 经 trace 证实为内部 monitor 在 30.455 秒取消、最终 499，并非外部客户 502。

## 验证

- `bun scripts/cli.ts check --syntax-only`：11/11 通过。
- `git diff --check`：通过。
- `codex-pool plan` 正确解析模板，但被既有本地 `config.toml.yjxm1221*` 缺失阻断；与本次 YAML 规则无关。
