|
|
662f8f02b6
|
fix(channels): 商汤扫码链路重建 + 双区登录 + 凭据过期口径 + 四条老化判据
① 商汤（Raccoon）扫码「链接无效」——两个真根因
- 登录页 /login/mp 已被站点删除（Next 路由 404，实测只有 404 页）；
- 旧实现本地随机造 qrcode_code，而上游早已不认自造码：旧端点
/api/web/auth/v1/login_with_qrcode_code 对任意 code 恒回 pending
（服务端没有该会话）⇒ 扫码永远完不成，账号一直是空凭据。
修法：改为上游现行 IAM 流程（逐行对齐其网页客户端 auth chunk）——
POST /api/iam/v1/auth/mp/qrcode 建会话 → 链接用
/login?code=…&appname=…&source=platform（实测 200 + 微信扫码面板）
→ 轮询 /api/iam/v1/auth/mp/qrcode/login（IAM code:"OK" 与旧 code:0 都认）。
服务端建码失败才退回旧本地码并打 warn。UI 对扫码流程改文案为
「用微信扫码」（原本文案会让人以为点开就自动登录）。
生产实测：链接 HTTP 200、轮询回 pending（会话真实存在）。
② 双区登录（P7）
- 凭据增加 region（intl|cn，缺省＝历史行为）；start_login 接受 region，
会话按区域选端点，完成登录写进凭据；
- CodeBuddy：cn=copilot.tencent.com（platform=ide）/
intl=www.workbuddy.ai（platform=workbuddy-ai，X-Domain、
X-Product-Code、UA 按区域；实测 auth/state 回 200 信封）；
- Qoder：intl=openapi.qoder.sh+qoder.com（client_id e883ade2-…）/
cn=openapi.qoder.com.cn+qoder.cn（client_id 不同 732aef47-…，照参考
QODER_CN）。CN 无公开 chat 端点 ⇒ CN 只做登录/领取；
- UI：buddy/qoder 详情页增加「＋国际区」按钮。
③ 凭据过期时刻的时区口径（P6 真根因）
credentialExpiresAtMs 把 ISO 过期时刻按本地时区解析，而 codearts 给的是
UTC ISO（2026-10-19T16:42:43.06Z）⇒ 本机 +08 下过期时刻虚早 8 小时 ⇒
refresh_creds 每 30 分钟都判"已过期"并对华为云真打一次 STS（token 本还有
23 小时寿命）。改为按声明时区解析（Z / ±hh:mm / 无后缀=UTC 三种形态同一
epoch），补 TestCredentialExpiresAtMsParsesISOAsUTC。
④ 四条老化/假红判据
- TestCreditsPoolReason*：account_add 触发的选号会用构造期默认余额 (0,0)
先查一次并缓存 60s ⇒ 之后改假上游读不到（"余额 100 却报 exhausted"）。
harness 改余额后清 TTL 缓存（__ttl_reset_probe，与生产同一实现）。
- TestAccountReorderActually... / TestPoolListOrderIsDeterministic：随
「一通道一源」失效（按 channels-buddy-<acct> 过滤恒得空）。改写为——
重排必须切换服务账号（新增 __chosen_account_probe），顺序确定性改为断言
选号顺序（__rank_accounts_probe）由 id 稳定决定。
- channels.lua 顶层 local 余量：区域表与 5 份适配器源码常量收进 plugin.K
（TestChannelsLuaHasLocalHeadroom 需要 ≥10 槽位）；ZCode 适配器源码里的
CLI_PREFIX 必须留在源码内（适配器沙箱没有 plugin 全局）。
⑤ 错误文案
openai_error 增补腾讯 codebuddy 三层嵌套 {error:{data:{code,msg}}}：实测
429 code=14018「额度已用尽」此前落到"不识别"，客户端只看到通用文案。
验证：core 434s 全绿、lua 62s 全绿、provider 全绿；生产已部署并实测
raccoon 链接 200 / trae 非流式 200 / zcode 适配器加载。
|
2026-10-20 08:27:28 +08:00 |
|
|
|
6eeb5832a3
|
fix(provider): 上游错误文案别再丢 —— 补网关/腾讯错误体形状 + 修误导性日志
## 发现路径：读生产日志（不是测试报红）
```
unhandled upstream error body (adapter "openai" lacks transform_error):
status=404 body={"error_msg":"404 Route Not Found"}
unhandled upstream error body (adapter "buddy" lacks transform_error):
status=400 body={"code":11101,"msg":"Non-stream chat request is currently not supported",...}
```
### ★ 缺陷 A：错误体形状漏了「网关」与「腾讯系」两类
`__prelude.openai_error()` 只认 `error.message` / `error`(裸串) / `{code,message}`
/ `detail` / HTML `<title>` / 裸文本 六种，**没有** `error_msg`（华为/APISIX 网关）
与 `msg`（腾讯系用 msg 而非 message）⇒ 返回 nil
⇒ 客户端只看到 `api error 404: unknown error`，**而 body 里明明有可用文案**。
修法照参考（llm-adapter.ts:524 `errorDetail()` 显式认 `error_code`/`error_msg`；
buddy-adapter.ts:576 认 `msg` + `displayMsg.{zh,en}`）：
- 新增 `{error_msg}` / `{msg}` / `{error_code,+error_msg}` 三种形状；
- 新增 `displayMsg.{zh,en}` 本地化文案，**排在最前**（参考注释明说"本地化文案
最可读"；其早期实现只读 `error.*`/`message` ⇒ 全部落空 ⇒ 把 291 字符原始
报文糊进错误提示，而服务端早已备好中文说明）。
覆盖 7 个用共享前导的适配器：buddy/deepseek/github/groq/kimicode/openai/sensenova。
### ★ 缺陷 B：内核那句日志会把人带偏
措辞是 `adapter %q lacks transform_error`，但 **openai.lua:139 与 buddy.lua:166
都明明定义了该钩子** —— 真实原因只是它**返回了 nil**（认不出那个形状）。
我照着这句话去适配器里找"有没有这个函数"，查了几轮才发现函数在、是返回值空。
修法：内核直接查事实（`p.vm.HasFn(adapter, "transform_error")`），
两种原因**分开措辞**，不再猜。
## 判据
`internal/lua/adapter_prelude_error_shapes_test.go`：
- 12 个形状子用例（4 个新增 + 6 个回归 + 2 个 displayMsg），
**装载仓库里真实的 openai.lua**（含共享前导），不是自造桩 ——
第一版用空 VM 跑，12 个全 FAIL（`adapter openai not loaded`），
那等于什么也没验。
- 配对判据 `...StillReportsUnknownShapes`：真正认不出的形状仍须 `ok=false`，
防止"为了让上面通过就把『抽不出』和『没这个钩子』混为一谈"。
- 变异：删掉新增的 error_msg/msg 分支 ⇒ APISIX 用例报红。
## 备注
`anthropic/gemini/mistral/ollama/opencodezen/qwen38/trae` 有自己写的
`transform_error`，不走共享前导，**未获得**本次新增形状（各自协议的错误体
本就不同）。此处只修共享前导的 7 个。
|
2026-10-17 00:37:32 +08:00 |
|
|
|
8e2d384a7b
|
feat(channels): Gemini 用插件自装的私有协议适配器（channels-gemini）
Cloud Code 凭据**不能**打公开的 /v1beta/models/{model}:generateContent。
参考 gemini.ts 点名三件必须保留，我们此前**一件都没有**（gemini.lua 产的是
公开的 contents/parts 裸体、一个身份头都不发，端点还指着公开路径）：
1. **身份五头逐字写死、不许随机**，且**不带** x-goog-api-key /
x-goog-api-client（User-Agent/x-client-name/x-client-version/
x-machine-id/x-vscode-sessionid）
2. **流式刻意不带 Accept**（抓包一致）
3. **信封逐层字母序序列化**（上游按字节比对；Go 的 encoding/json 对 map
自动字母序，而我们用 json.encode，故须自己排——实现 sorted_json）
信封形状（私有端点要的不是裸 contents）：
{model, project, request:{contents, systemInstruction, tools,
generationConfig, sessionId}, requestId, userAgent}
响应也是信封（candidates 嵌在 response 里）→ 必须**剥一层**，否则下游
拿不到 candidates，表现为"模型没回话"（静默失败）。
另加前导助手 gemini_response / gemini_stream_chunk（candidates/parts/
usageMetadata → 统一信封；STOP→stop 等 finishReason 映射）。
★ 踩到的两个坑：
- **Lua 长字符串里不能有字面 NUL 字节**（Python heredoc 写的 "\0" 变成了真
字节）→ Lua 报 "unfinished long string near '<eof>'"，且报在文件末尾，
完全指不到现场。
- **本 Lua 构建不支持按位异或 `~`**（unexpected symbol near '~'）→ FNV-1a
的 XOR 改用算术等价形式。参考自己明言 sessionId 的哈希本体未反推出来、
数值不与原版逐字相同，所以这里要的是**确定性 + 依赖维度正确**
（吃 project 与首条文本、不吃 model），不是数值一致。
- 另给三个自装适配器统一加**本地预编译护栏**：内核装载失败只回"源码无法
编译"不给行号；先 load 一次就能拿到行号（上面两个坑都是靠它定位的）。
⛔ 仍不做：gemini-sigstore（签名持久化，268 行）——推理走无状态适配器，
插件侧缓存会成为死代码。理由已记在 docs/channels-parity.md。
判据（internal/lua/channels_gemini_adapter_test.go）：走真实路径断言
身份五头逐值、**反向断言** x-goog-api-key/x-goog-api-client/Accept 不得出现、
信封五个顶层字段齐全、顶层键字母序（解析式校验，不是字符串匹配）、
响应剥信封后 content/finish_reason/token_usage 都到位。
回归：internal/{lua,core,provider,gateway} 全绿。
|
2026-10-13 23:42:04 +08:00 |
|
|
|
a7a0c6adee
|
refactor(lua): 11 个适配器改用共享前导 —— 删掉约 20KB 逐字重复
按前导抽出三块共通实现（都是实测逐字节相同的）：
| 钩子 | 原本重复 | 各 2.2KB |
|---|---|---|
| transform_stream_chunk | github/groq/kimicode/mistral | 2210B × 4 |
| transform_response | openai/groq/kimicode/mistral/github | 2206B × 5 |
| transform_error | deepseek/github/groq/kimicode/openai/sensenova | 292B × 6 |
适配器总行数 2409（收工前 groq 单文件 146 行 → 46 行）。
★ 两个必须记下的教训（都在本提交里踩到并修好）：
1. **抽公共代码要抽最全的实现，不是最小的**。我先抽了 transform_error 的
最小版（只认 {error:{message}}），打挂了 TestOpenAITransformErrorEnvelopes
的 6 个子用例 —— 最小版丢掉了 HTML 错误页、裸文本、扁平 {code,message}、
FastAPI {detail} 等形状。openai.lua 原有的 1580B 版本才是该进前导的那份。
抽最小实现是**静默降级**：不报错，只是少认几种错误体。
2. **抽出共性时不能丢掉"非共性但重要"的细节**。openai_response 我漏了两处：
reasoning_content 透传、以及 tool_calls 的 id 规整（safe_tool_id）。
后者尤其危险 —— 本网关是扇出路由器，一个非法 id（"bash:0"）会被回放到
每个 Claude 上游导致整条 AUTO 链失败；且**流式与非流式必须同规则**，
否则同一请求两条路径产出不同 id（实测报错：
流式 "bash_0_40248ca0" vs 非流式 "bash:0"）。现两条路径都走
__prelude.tool_id。
判据：TestPreludeRefactorIsByteIdentical —— 固定输入下逐字节比对
（含"arguments 必须解码成表""usage-only chunk 必须是 done:false"
"arguments 不得留原样 JSON 字符串"等反向断言），并覆盖错误体 6 种形状
与"非 OpenAI 形状必须返回 ok=false"。
另修 channels_pool_test：断言改为**关系**（关一个模型源里少一个）而非写死
数量 —— 兜底目录会随对齐进度变化（minimax 3→4），写死数量会把正常的目录
扩充变成测试失败。
回归：internal/{lua,provider,core,gateway} 全绿。
|
2026-10-13 22:51:50 +08:00 |
|
|
|
741edfea98
|
feat(lua): 适配器共享前导 —— 消除 12680 字节的逐字重复
问题（实测证据，按钩子做字节级哈希分组）：
transform_response github/groq/mistral 三份完全相同（2207B × 3）
transform_stream_chunk github/groq/kimicode/mistral 四份相同（2211B × 4）
transform_error deepseek/github/groq/kimicode 四份相同（293B × 4）
合计 12680 字节完全重复。openai.lua 自己的注释就写着
「(anthropic.lua carries the same helper; Lua adapters have no shared
prelude.)」—— safe_tool_id 在 openai.lua 与 anthropic.lua 各复制了一份。
参考插件有 src/openai-compat.ts（1196 行，12 个 adapter 里 8 个 import），
我们没有对应物。本提交补上这一层。
做法：**编译期把一份中性助手库拼在适配器脚本前面**，注入点在
LoadAdapterSource —— 适配器有三个编译点（worker boot / HasFn 探针 /
inspectScript），全部源自这里存进 pool 的 script 文本，拼一处即全覆盖；
且不像运行时 SetGlobal 那样会在热重载/池重建时丢失。
助手只做**协议层面的中立清理与组装**，不含任何厂商名（守住内核零厂商名
纪律）：decode_body / strip_control（剥内核私有控制字段 —— 那是网关内部
约定，v2 改一次就要改 12 个文件）/ unified_skeleton / finish_reason /
usage（含 cache 细分，属协议族已知变体）/ choices / tool_id（路由器性质：
坏 id 会被回放到每个 Claude 上游，一票否决整条 AUTO 链）/ derive_key。
判据两条：
- TestAdapterPreludeInjectedAndCorrect：不只断言存在，抽查**语义值**
（end_turn→stop、tool_use→tool_calls、合法 id 原样透传、非法 id 带摘要
改写、cache_hit 从 prompt_cache_hit_tokens 取）
- TestAdapterPreludeDoesNotChangeExistingAdapters：旧适配器（自己实现全部
钩子、不引用前导）输出逐字节不变
回归：internal/lua + internal/provider 全绿（16 个适配器行为不变）。
|
2026-10-13 22:34:13 +08:00 |
|
