fix: 增加522上游故障切号规则

2026-07-16 13:53:41 +02:00
parent baedea5784
commit 0d6adb373d
3 changed files with 34 additions and 0 deletions
@@ -55,6 +55,10 @@ runtime:
            keywords: [concurrency limit exceeded, upstream service temporarily unavailable, input must be a list]
            durationMinutes: 1
            description: 明确命中 504 上游并发限制、暂时不可用或 Responses input 列表兼容错误时短时冷却当前账号。
+          - statusCode: 522
+            keywords: [upstream request failed]
+            durationMinutes: 1
+            description: 明确命中 522 上游连接超时并返回通用失败信息时短时冷却当前账号。
          - statusCode: 524
            keywords: [upstream request failed, service temporarily unavailable, overloaded, concurrency limit exceeded]
            durationMinutes: 1
@@ -0,0 +1,26 @@
+# 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 规则无关。
@@ -295,3 +295,7 @@
 ## R6 [completed]

 处理 `529 Overloaded / API is at capacity` 客户可见错误：以 Sub2API 原生 Ops 证据锁定未触发 failover 的账号和规则缺口，在通用非 auth API-key 临时不可调度模板补 529 一分钟冷却并精准批量应用，排除 lyon9801，完成 runtime 回读和修复后短窗口复核，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R6_Task_Report.md)。
+
+## R7 [completed]
+
+修复近期真实上游 522 穿透：基于账号 https://sub.yjxm1221.top pro 0.06 请求 24cc5f1b-e1e8-4ca1-b73d-b4735e55b3d4 的原生 Ops 证据，在通用 codex-upstream-failover 模板增加 522 与真实响应关键词 upstream request failed 的 1 分钟临时不可调度规则，dry-run 后精准批量应用到已配置同类策略的非 lyon API-key 账号并逐账号回读；同时纠正内部 monitor 502、客户 499 和 upstream phase 524 不应计为客户可见错误的分析口径，不修改 Sub2API 源码、版本或外部哨兵，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R7_Task_Report.md)。