|
|
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 |
|
