|
|
9521a35a03
|
feat(channels): Qoder 用插件自装的 channels-qoder 适配器 —— 排队与额度耗尽分开说
## 为什么
Qoder 的错误信封是**双层编码**的，且两个业务码语义**恰好相反**：
| 码 | 含义 | 正确处置 |
|---|---|---|
| `10605` | 模型排队 | **暂时**受阻 —— 等若干秒就能过 |
| `110` | 当日额度耗尽 | 立刻重试 / 等 15 秒 / 等 30 分钟，结果一样 ⇒ **必须立即失败** |
参考实测（2026-09-27 用户报障）：`110` 原先被归成通用的「服务端错误」→
**白重试 5 次**（≈15.5 秒），用户看到「重试延迟：7220毫秒」。
而我们此前用通用 `openai` 适配器，对它只能产出
`10605: {"isQueued":true,…}` —— 用户根本看不出是排队还是额度用完。
## 做法：厂商知识留在插件域（内核零厂商名）
照 `channels-trae` / `channels-gemini` 既有机制，本插件自装 `channels-qoder`。
内核只把 `transform_error` 的返回文本当作**客户端可读原因**，不认识任何厂商码。
★ **两个踩过的坑（都写进代码注释与判据）**：
1. **内层没有 `code` 字段** —— 那是 SSE 错误帧的 `message`（一个 JSON 字符串）。
参考第一版要求「必须命中 code 才算排队」，导致内层形态被判成非排队，
SSE 通道的修复**静默失效**（探针显示 sleep=0、错误照旧）。
判据改为：命中 `code=10605`，**或**直接出现排队字段（`isQueued`/
`serviceAvailable`）。`message`/`data`/`result`/`body` 都要展开并**再解析**。
2. **必须先在带排队字段的节点上取值** —— 外层 `root` 只有 `code`，
没有 `retryAfterSeconds`/`queueCount`。一命中就返回会让这两个参数**永远丢失**
（实测：只输出「排队中，请稍后重试」，参数全丢）。
3. **额度关键词必须窄** —— 只认 `billing daily count exceeded` /
`daily count exceeded` / `billing_error`。`quota`/`balance` 这类泛词会把
模型正文里讨论「余额」误判成故障。
## 判据（5 组，全部咬住真实行为）
`TestQoderAdapterParsesQueueAndBilling`：
① 双层编码取到内层的 30 秒 / 12 个排队；② **内层无 code** 也必须识别（参考的坑）；
③ `110` 说成额度耗尽、且明确「重试无用」、**绝不说成排队**；
④ 泛词 `quota`/`balance` 不误伤；
⑤ **与通用 openai 适配器对比** —— 断言通用器**做不到**这件事，
否则这个专用适配器就没有存在理由（防"加了但没用"）。
回归：9 个包全绿；内核非测试代码零厂商名。
|
2026-10-14 20:00:58 +08:00 |
|
