|
|
fc5326402f
|
fix(channels,provider): 渠道模型不可用 + 额度异常的三个根因
## 背景
用户报三问题：① channel 注册的模型无法使用；② 额度显示依旧异常；
③ 其他渠道应也存在类似问题。三条全部核实并给出结论（③ 见文档）。
## ① 网关解不开 `源名:模型名` 限定名（internal/provider/registry.go）
`ResolvePinned` 用 `strings.IndexAny(model, "-:/")` 找**第一个**分隔符。
而渠道源名形如 `channels-trae-b8dd6b3df30e`（**含 `-`**），于是
`channels-trae-b8dd6b3df30e:Doubao-Seed-2.1-Pro` 被切成
src="channels"、model="trae-b8dd6b3df30e:Doubao-Seed-2.1-Pro"
⇒ 源名永不匹配 ⇒ `Resolve()` 返回 nil
⇒ 客户端看到 `model "..." is not configured`。
**为什么这个写法必须支持**：本实例有 **44 个模型被多源同时提供**
（`glm-5.2` 由 6 个源提供），WebUI 的模型下拉框用 `源名:模型名` 作为
option value 是**有意设计** —— 用户必须能指定"从哪个源调用"。
修法：抽 `splitPinned()`，**按已知源名做最长前缀匹配**（源名是已知集合，
这是唯一可靠办法），保留旧 `-:/` 兜底以兼容非源名形态。
`EffectiveModel` 同步修（同一拆分规则，避免两处漂移）。
## ② trae 适配器三连错（internal/lua/plugins/channels.lua）
三个错误逐层叠加，每个都被上一层掩盖：
**(a) 没有 `build_headers`** ⇒ 内核兜底发 `Authorization: Bearer`，
而 trae 推理端点要 `Cloud-IDE-JWT` + 设备身份头 ⇒
401「We're sorry, but we are not able to authenticate you」。
→ 与上一轮「额度不可用」是**同一根因的两个出口**（额度端点修了、推理端点漏了）。
教训：修"某一族请求的鉴权"时，必须把该族的**所有出口**列出来逐个对齐。
**(b) header 常量的值是错的**（照参考 trae-product.ts 的 TRAE 配置逐项核对）：
· `X-App-Id` 抄成 `6eefa6c9`，真实是 `6eefa01c-1036-4c7e-9ca5-d891f63bfcd8`
· `app_version_code` 用了 `0.1.52`，真实是**日期式** `20260811`
⇒ 上游 `4001 bad request: binding: expr_path=app_version_code,
cause=parameter type does not match binding data`
**(c) 流式转换完全不对**：TRAE 是 **SOLO 自定义 SSE**：
event:output → data:{"response":"###","reasoning_content":null,...}
正文在 `response`，推理在 `reasoning_content`。
· 套 `__prelude.openai_stream_chunk` ⇒ 无 `choices` ⇒ `empty stream`
· 改成 OpenAI 外壳 `{choices:[{delta}]}` **仍然空** —— 内核
`json.Unmarshal(unified, &UnifiedChunk)` 解的是**扁平结构**，外壳字段全被丢弃
⇒ 必须输出扁平 `{content, reasoning_content, usage, done, finish_reason}`。
⚠️ 内核只把 `data:` 行交给适配器（`event:` 行在 provider.go 被丢弃），
因此判别帧类型只能靠**内容特征**（`response` / `reasoning_content` /
`finish_reason` / `prompt_tokens`），拿不到 event 名。
## ③ 余额恒为 0（同文件 balance.total_fn）
读的是 `p.credits_limit`（pack **顶层**）—— 该字段**根本不存在**。
真实路径是 `pack.entitlement_base_info.quota.credits_limit`
（参考 trae-credits.ts:341）+ `pack.usage.credits_amount`。
实测上游：`免费`(无该字段) / `每月登录赠送`(500) / `签到奖励`(100) ⇒ 实际 600。
修法：读嵌套路径 + 保留顶层兼容 + `usage_summary.{total,consumed}_amount` 兜底。
修后余额 600 → 实测 598.516（真实扣减）。
## ④ 夹具与生产形状不一致（internal/core/channels_trae_test.go）
夹具原先返回**扁平** `{"Token":...}`，与生产 `{"Result":{"Token":...}}` 不符
⇒ 「代码只读顶层」这个缺陷在夹具里**恰好是对的**，所有 trae 判据都绿。
**夹具形状错 = 判据必然虚假通过**。这是 ExchangeToken 缺陷藏了两轮的原因。
## 判据（新增，变异 4/4 咬住）
- `internal/provider/registry_pinned_name_test.go`（4 用例）
- `internal/core/channels_trae_chat_headers_test.go`（3 条）
- `internal/core/channels_trae_solo_sse_test.go`（2 条）
- `internal/core/channels_trae_credits_hdr_test.go`（1 条）
- `internal/core/channels_trae_exchange_shape_test.go`（2 条）
## 文档
`docs/channel-repair-plan.md`：现状快照（生产实测）+ 各渠道缺陷矩阵 +
后续计划（P0-P4）。**如实记录**：其余 4 个渠道（zcode/cline/gemini/qoder）
有同类缺陷风险，但**账号数均为 0、无法做生产验证**。
## 生产已实测
- `channels-trae-...:Doubao-Seed-2.1-Pro` → 80 帧，正文 27 + 推理 299
- `channels-trae-...:glm-5.2` / `channels-buddy-...:hy4-preview` → OK
- `credits/status` → active:true, dailyCredit:100, todayCheckedIn:true
- `credits/balances` → total:598.516 credits
|
2026-10-17 17:38:58 +08:00 |
|
|
|
cf53d72af4
|
fix: 回退两处内核改动，channels 改为插件自持持久化（照参考实现）
用户指出「你又tm改内核？」—— 核对后确认两处本可避免：
1. internal/lua/vm.go +32 行 新增 base64_decode 全局函数
2. internal/lua/plugin_http_handler.go +16 行 InvokeHandler 补 markDirty
工作区已还原到 v2.0.2（git diff v2.0.2 = 0 行）。
参考实现（dsh-our-free-model/vendor/channel-pack）对同一问题的做法：
- 解 JWT：用**语言自带**的 `Buffer.from(..., 'base64url')`，从不为此改宿主。
→ 我改成了插件的纯 Lua b64url_decode（约 20 行），实测解出真 JWT 的
nickname/sub/exp 全对。
- 状态持久化：插件**自己 writeFileSync+renameSync** 写
`channel-pack/state.json`，从不依赖宿主 settings。
→ 参考还记下了同构教训（Gitee IKI7WT）：DSH 0.1.7 移除 settings.register()
后账号列表退化为纯内存；正解是**插件探测宿主能力、自持文档**，不是要求
宿主改。我的 markDirty 修法方向相反：把插件的数据安全外包给宿主某条
分发路径的实现细节。
- `.channels-store.json`（tmp + rename 原子替换），只放**索引与配置**
（账号条目含 credentialRef 而非凭据本身、模型黑名单、设置、事件日志）。
凭据仍在 .secrets/（0600），两者分离：即便文档泄露也不含 token。
- 变更点同步落盘（不用「置标志+定时 flush」）：本插件无 hooks、45 个端点
各自变更状态，还有大量内部互调；挂在某个边界就必须保证**每条**路径都
经过它，漏一条就是「操作成功但重启丢失」——正是本次要修的缺陷形态。
状态实测 ~1.7KB，写入只发生在运维动作上，不在请求热路径。
- 黑名单写入收口到 setModelDisabled（写点曾有 5+ 处，散着写必漏）。
- 存量迁移：读内核遗留 `.channels.state.json`（v2.0.4 内核写的）→ 写自有
文档 → **写成功才删**遗留（写失败还删=用一次迁移丢数据）；自有存储已存在
时也删遗留，否则内核 restore() 会在启动时用它覆盖。
1. **测试污染生产目录**（严重）：插件 storeDir() 读 /etc/llmsproxy/config.yaml
决定落盘位置，而既有测试都没隔离 → 一次全量测试把 26 个测试账号写进了
**生产** .channels-store.json（含 fixture-a/example 等夹具 id）。
prod 文件已删除（真实账号另有来源）；kernelTestCore 现在隔离插件目录，
且尊重调用方已设的值（多次「重启」需共用同一目录）。
2. model_set_disabled 改了写入口后仍引用已删除的局部变量（nil 索引崩溃）。
- TestChannelsStoreIsPluginOwned：状态写进**插件自己的**文件、不含凭据字段、
新实例读回。变异（markDirty 空操作）→ FAIL。
- TestChannelsMigrationKeepsLegacyOnWriteFailure：**写失败必须保留遗留文件**。
变异（无条件删）→ FAIL。（这条单独测：迁移成功后的删除有两条路径互相掩盖，
只测「最终文件没了」区分不出「写失败也删了」。）
- TestChannelsMigratesLegacyKernelState：遗留账号迁入内存 + 自有存储写出 +
遗留文件删除。
- 内核对照 v2.0.2：diff 为空。
go test ./internal/core/（78s）与 ./internal/lua/（63s）全绿；
全量测试后确认生产插件目录未被写入。
|
2026-10-13 09:34:13 +08:00 |
|
|
|
893857464d
|
feat(channels): TRAE callback 真实移植 —— token 直传 + ExchangeToken（照参考逐行）
此前 oauth_callback 是通用 OAuth 形态（直接拿 code 当凭据），与 TRAE 真实
行为不符。参考实现 trae-oauth.ts 的回调是 **token 直传**，本次照其行为移植：
parseTraeCallbackDetailed（决策表 5 行）：
行1 refreshToken 直传（或 userJwt.RefreshToken 回退）→ ExchangeToken 换新
access（请求体 ClientID/RefreshToken/ClientSecret:'-'/UserID 照抄，
响应取 Token）→ 凭据 = 新 access
行2 无 refreshToken 但有 userJwt.Token → 直接兜底，**不打** ExchangeToken
行3 只有 code/authCodeInfo → PKCE 流，明确报"暂不支持"而非含糊失败
（参考注释强调：判为无效会让用户往错误方向排查）
行4 全空 → 报"回调未携带 refreshToken / userJwt.Token / code"
行5 ExchangeToken HTTP 失败 → 错误指明 ExchangeToken 阶段
配套：
- PLATFORMS.trae 增加 callback = {mode="trae", exchange_url, exchange_body}；
- oauth_callback 按平台 callback.mode 分派（nil→code 旧路径不变，googleish 不受影响）；
- traeCallback/jsonField 新函数；set_endpoints 支持 callback.exchange_url 覆盖
（既是运维能力也是测试缝，与 device 端点同语义）；
- TestTraeCallbackBehavior：5 行决策表 + 行1 断言凭据来自假上游新 Token
（防"把回调原值当凭据"）、行2 断言 ExchangeToken 零调用（防多余上游请求）。
回归：channels/trae/device 变异/压力/legacy/保险库/e2e 全绿。
|
2026-10-11 22:35:18 +08:00 |
|
