seewe/sub2api
1
0
Fork 0
mirror of https://github.com/Wei-Shaw/sub2api.git synced 2026-10-15 23:22:59 +08:00
Code Issues Packages Projects Releases Wiki Activity
7,597 Commits 46 Branches 62 Tags
43768680d38ccdbd8fffc2cb91d3c1fc778a61c6
Commit Graph
71 Commits
This Branch
This Branch
All Branches
Author SHA1 Message Date
li 1dc0a09009 fix(openai): ctx_pool WS ingress 下发前改写上游容量降载错误码 
上游容量降载（server_is_overloaded / slow_down）被 ctx_pool 的 ingress 直写路径
原样转发给客户端。Codex CLI 按闭集判定，这两个码属致命集，客户端打印
"Selected model is at capacity" 并直接终止会话，不退避重试。

仓库已有 sanitizeOpenAICapacityShedErrorCodeForClient 处理这件事，且注释写明了
Codex 的闭集判定与"账号状态判定使用改写前原始 payload"的前提。它此前只在
HTTP/SSE（openai_gateway_response_handling.go）与 http_bridge
（openai_ws_http_bridge.go）两条路径被调用，ctx_pool ingress 直写路径是唯一漏掉
的一条——同一账号同一时刻切到 http_bridge 就能正常退避重试。

改写结果写入独立的 clientMessage，不动 upstreamMessage：写出点之后的
markOpenAIWSClientVisibleFailure 与 handleOpenAIWSTerminalTransientFailure
仍按原始 payload 判定账号状态，与 http_bridge 的写法一致。

新增用例覆盖改写生效与改写范围两侧（非容量类错误码必须原样下发）。
 2026-08-31 16:53:57 +08:00
li 8f5451587e fix(apicompat): Anthropic→Responses 流式转换在 thinking 块前关闭 message item 并推进 content_index 
thinking 块开始时不关闭已打开的 message item，直接覆盖 CurrentItemType/
CurrentItemID，累积的助手文本既不进 state.Outputs 也拿不到 output_item.done，
response.completed 只带 reasoning——客户端收到「成功但无输出」。同 switch 的
tool_use 分支本来就先调 closeCurrentResponsesItem，只有 thinking 漏了。

content_index 只在 item 打开时置 0，从不推进。同一 message item 里第二个 text
块会再发一次 content_part.added(content_index=0)，与第一个 part 撞在同一下标，
SDK 累积式 helper 按 content[content_index] 写入时后者覆盖前者。反方向
responses_to_anthropic.go 有三处 ContentBlockIndex++，正方向一处都没有。

新增用例覆盖两条坏顺序，外加一条生命周期不变式用例（output_item.added 与
output_item.done 必须配平、terminal 事件按announce 顺序逐项携带）。
 2026-08-31 16:15:08 +08:00
li e652f6e20a fix(monitor): 配额抓取在 singleflight 执行体内重查缓存，消除重复上游查询 
ChannelMonitorQuotaFetcher.Fetch 顶部的 cachedSnapshot 与随后的 flight.DoChan
之间存在一个窗口：goroutine A 判定缓存未命中之后、真正入队之前，goroutine B 的
flight 可能已经跑完、写好缓存，并且它的 singleflight key 也已被摘掉。A 于是不会
并入 B 的那次飞行，而是另起一个新 flight，对同一账号再打一次上游——正是
singleflight 想要消除的重复查询。

多个监控可以关联同一账号，interval 最小 15s，国产配额服务自身无缓存，
这条路径的全部意义就是防止打爆上游配额端点（见文件头注释）。

修复：把 flight 执行体提为具名方法 fetchShared，开头重查一次缓存。
这次重查必然命中，所以合并是确定的而非尽力而为：storeSnapshot 发生在执行体
返回之前，singleflight 删 key 发生在返回之后，因此「能新起一次飞行」必然蕴含
「上一次的快照已经可见」。

该窗口也是主线 CI 上 TestQuotaFetcher_ConcurrentFetchesShareSingleFlight
间歇性失败（expected: 1, actual: 2）的成因，本地 -count=900 复现 3 次（约 0.33%），
带修复后 -count=1700 零失败。

新增两条确定性用例：既有并发用例只能以约 1/300 的概率撞上该窗口，故直接钉住
窗口本身——fetchShared 就是 flight 的执行体，直接调用它等价于「已越过顶层缓存
判定、拿到属于自己的那次飞行」这一状态。另一条守住重查不得退化成无条件短路：
缓存过期后必须照常回源。
 2026-08-28 16:49:49 +08:00
li 0756c98102 fix(frontend): 批量编辑显式提交 codex_fingerprint_mode=off，修复无法关闭指纹收敛 
批量编辑选「关闭（默认）」时，buildUpdatePayload 先 ensureExtra() 建出 extra
再 delete 掉唯一的键，payload 退化成 {account_ids, extra:{}}，被后端
len(req.Extra) > 0 判为空更新，直接 400 "No updates provided"；device/session/full
则正常。即便后端放行空 extra 也无济于事：批量更新走 JSONB 顶层合并
（extra = COALESCE(extra,'{}') || payload），删掉 payload 里的键只表示
「本次不更新该键」，清不掉账号上已有的 device/session/full。

根因是把 Create/Edit 的写法直接搬到了 Bulk：那两个表单提交完整 extra 对象、
后端 SetExtra 整体覆盖，删键确实等于清除；批量接口只合并增量键，两种持久化
语义不能共用同一套写法。

改为 off 也显式落键，与本函数里其它「关闭/清除」字段一致——codex_cli_only
直接落 false（EditAccountModal 相邻注释已写明「关闭时显式写 false，避免 extra
为空被后端忽略导致旧值无法清除」）、load_factor 落 0、proxy_id 落 0。

读取侧完全等价，不改变 #5610 定下的语义：codexFingerprintModeFromExtra 对
空值/非法值走 default 回落 off，对 "off" 命中同一分支；
ShouldEnsureCodexFingerprintSeedForExtraUpdates 也只在 device/session/full
时要种子，显式 off 不会触发种子创建。

顺带给「编辑该项」勾选框补 id（同区域 Select 早有 data-testid，兄弟开关
codex_cli_only 也有 id），否则新增用例无法定位该控件。

新增 3 条用例：主复现（默认 off + 勾选编辑 ⇒ 提交 codex_fingerprint_mode=off，
并断言 extra 非空以钉死 400 那个形状）、显式 opt-in 仍原样提交、未勾选时不写入该键。

Fixes #6327
 2026-08-28 16:20:14 +08:00
li c83dced4ba fix(openai): 入站 WS 的客户端正常关闭与断开不再计为账号故障 
ingress WebSocket 收尾处只把 *service.OpenAIWSClientCloseError 且状态码为 1000
的情况认作正常关闭，其余全部落到 shouldReportOpenAIWSProxyAccountFailure ——
而它只排除 model-switch 与 session-preempted 两种。两种完全正常的结束因此被
误判为上游/账号故障：

- 客户端干净关闭：coder/websocket 直接回裸 coderws.CloseError{Code: 1000}，
  ReadOpenAIWSClientMessage 把 conn.Read 的错误原样返回，没有任何一层把它包成
  *OpenAIWSClientCloseError，所以 errors.As 对该类型必然为假。
- 客户端中途断开：ReadOpenAIWSClientMessage 在 controlCtx.Done() 分支用
  StatusGoingAway(1001) 收尾并以 context.Canceled 为 cause，「只认 1000」匹配不到。

两者都会走到 ReportOpenAIAccountScheduleResult(success=false)，进而喂给
ObserveOpenAIAPIKeyHealthFailure 与 scheduler.ReportResult，累积到阈值即把上游
账号熔断出调度池——客户端按一次 Ctrl-C 就在扣上游账号的健康分。

同文件的 summarizeWSCloseErrorForLog 一直用 coderws.CloseStatus 读关闭码，就在
该判断之后 12 行被调用，于是同一条 WARN 会打印
close_status=1000(StatusNormalClosure) 的同时把账号记为故障。

失败归因的政策仓库早有明文：同包 failover_loop.go 的 failoverClientGone 写着
「客户端断开后 failover 必须静默终止……并被误报成账号耗尽」。本次把 WS ingress
补齐到同一条规矩。

判定收窄：只豁免 1000 与 context.Canceled。1001 不整类放行——网关也会因自身原因
用 GoingAway 收场，客户端取消那一支已由 context.Canceled 覆盖；
context.DeadlineExceeded 同样不放行，空闲超时那条本就被包成 1000 走前一个判据，
其余 deadline 是真实停滞。

Fixes #6105
 2026-08-28 13:17:43 +08:00
li 81ac8ccd64 fix(openai): 非流式路径按流式同一套判定处理 HTTP 200 终止失败事件 
stream=false 时上游仍可能回 SSE（其他 sub2api 实例、部分 OpenAI 兼容上游），
容量/限流错误经 HTTP 200 的 response.failed / error 终止事件回传。
handleSSEToJSON 与 handlePassthroughSSEToJSON 把所有终止事件塞进固定 502
（writeOpenAINonStreamingProtocolError），而几百行外的流式读取器对同一帧走
openAIStreamFailedEventShouldFailover / openAIStreamErrorEventShouldFailover
判定并返回 UpstreamFailoverError。

同一个上游、同一个事件，仅因请求上的 stream 标志而结果相反：流式换号，
非流式把上游原文直接抛给客户端，池里还有可调度账号也不换。

新增 nonStreamingTerminalFailureFailover，在两条非流式路径上复用流式的同一套
分类，并按 terminalType 分派——裸 error 帧走更保守的那个（仅正向识别为瞬时才
换号），response.failed 走完整的那个，与流式读取器逐字一致。

安全前提：响应体已被 ReadUpstreamResponseBody 完整缓冲，判定发生在写出任何
语义字节之前。能否真正换号仍由 handler 的 openAIForwardMayFailover 用
keepalive 调整后的写出量仲裁（#3887），service 侧只额外拒绝 IsResponseCommitted
与 account 为 nil 的场景，不重复实现心跳判定，避免与 handler 口径分叉。

行为变更：未被分类为不可重试的泛化 response.failed 在非流式路径上由「回写 502」
变为「换号」——这正是与流式对齐的结果。既有用例
TestHandleSSEToJSON_ResponseFailedReturnsProtocolError 传的是 nil account，
无账号则无可换对象，故其断言原样保留，仅更名为 ...WithoutAccountReturnsProtocolError
并注明原因；带真实账号的同一报文由新增用例钉死。

Fixes #5281
 2026-08-28 11:36:08 +08:00
li 1e8745c887 fix(payment): EasyPay 补全 mapi.php 回传的相对 payurl/qrcode 
createAPIPayment 把上游 mapi.php 返回的 payurl/payurl2/qrcode 原样落库。
EasyPay 兼容上游对该字段并不统一：部分实现回站点根相对路径（如
`/api/pay/toapp/<order>`）而非完整地址。而链路上没有任何一层修复它——
sanitizeCreatePaymentResponseDetails 只剥 NUL 字节就写进 pay_url/qr_code，
前端 PaymentQRCodeView.renderQR 又把 qr_code 直接喂给 QRCode.toCanvas。
结果二维码的载荷是一段裸路径：微信扫出来是文本，pay_url 则落到网关自己的
域名下 404，用户无法进入上游收银台。

同文件的 createRedirectPayment 本就自行拼绝对地址（apiBase + "/submit.php?"），
只有 mapi.php 这一支透传；Alipay provider 也早已写明「Setting it as QRCode
would let the frontend render an unscannable image」并拒绝产出不可扫的值。
本提交让 EasyPay 与这两处对齐：按实例配置的 apiBase 解析上游回传的引用。

仅补全以 "/" 开头的引用。带 scheme 的一律原样返回，覆盖绝对 https:// 收银台
地址与 weixin:// / wxp:// / alipays:// 等 app 深链；无前导斜杠的引用同样不动，
因为二维码载荷常是不透明 token，把 "OrderToken123" 改写成
"<apiBase>/OrderToken123" 会毁掉一个当前可用的载荷，比本 bug 更糟。

payurl2 优先于 payurl 的选择语义保持不变。

Fixes #6292
 2026-08-28 11:09:34 +08:00
li 4a02e54171 Merge remote-tracking branch 'origin/main' into fix/anthropic-chat-bridge-reasoning-passback 2026-08-27 13:40:29 +08:00
li 9192426d2e merge: 合入 origin/main，与新增的 service_tier 字段并存 
主线在 ResponsesResponse 与两处流式事件上新增了 service_tier；本分支新增的
created_at 与之并列，无语义冲突。同时跟进 ChatCompletionsResponseToResponses
新增的 functionTools 形参。
 2026-08-27 13:40:07 +08:00
li d077002eba fix(openai): 图片工具冷却不再由「模型回文字」这一请求级判据触发 
v0.1.181 起，/v1/images/generations 只要上游回了文字而没回图，就给账号写 30 分钟
openai:image_generation 模型级冷却。该判据由 openAIImagesTextFallbackErrorForText
从模型的自然语言输出**推断**而来，只说明这个 prompt 这一轮模型选择了说话——
仓库自己的既有用例 fixture 就是一句「Here's a polished image prompt for your request.」。

更糟的是同一个错误被判为可重试（502 → IsOpenAIImagesRetryableUpstreamError）并驱动
newOpenAIAccountFailoverError：一次闲聊回复会被逐个账号重试，沿途把每个账号都冷却掉，
表现为「开启后没多久账号就全部被限制」。

改为只在上游 error 帧点名该状态时才写冷却；网关自行推断的判据打上
SynthesizedFromModelText 标记并跳过。换号行为一字未动。

依据是仓库既有政策（alpha/search 路径原话）：工具端点的单次失败
「仍允许本次请求换号，但不修改任何账号状态」。

Fixes #6171
 2026-08-27 13:36:50 +08:00
li 3c5553e253 fix(responses): 网关合成的 Responses 对象补齐 created_at，修复严格客户端反序列化失败 
严格的 Responses 客户端（Rust serde 系，如 Codex / Grok CLI）把 created_at 声明为
必填字段，缺失即 `missing field 'created_at'` 直接读不出响应。

apicompat.ResponsesResponse 此前根本没有这个字段，六个构造点全部不写：
Chat→Responses 与 Anthropic→Responses 两座桥的非流式结果、response.created、
终止事件，以及两处手写的 response.failed 帧。

两个流式 state 早就在 New*State() 里采集了 Created 时间戳，只是没有出口——
反方向（Responses→Chat）每个 chunk 都老老实实发 created，正方向直接丢在地上。

原生 Responses 透传走 gjson/sjson 字节级改写，保留上游原样，不受影响；
本次只补合成路径。

Fixes #5601
 2026-08-14 11:05:29 +08:00
li 901a77cfb1 fix(apicompat): Anthropic→Chat 桥回传工具调用的 thinking，修复 DeepSeek 多轮 400 
/v1/messages 打到只支持 Chat Completions 的 OpenAI 兼容上游时，
anthropicAssistantToChatMessages 把历史 assistant 消息里的 thinking 块整块丢弃。
DeepSeek 的 thinking mode 要求产生工具调用的 reasoning_content 随该 assistant
消息回传，缺失即 400 —— 表现为「单轮正常，一进多轮工具对话必现失败」。

这些 thinking 块本来就是同一个文件的出站方向
(chatMessageToAnthropicBlocks) 用上游 reasoning_content 生成的，客户端只是
原样回传：桥自己造出来的东西，回来时被自己丢掉。

兄弟路径 Responses→Chat (buildChatMessagesFromItems 的 pendingReasoning) 早已
处理同一约束。本次把同一策略补到漏掉的这条桥上，作用域严格对齐：reasoning 只挂
到带 tool_calls 的 assistant 消息，纯文本轮次维持现状。

Fixes #5528
 2026-08-14 10:33:47 +08:00
li fd9ce53281 fix(openai): 探测响应未跑完时不再落标为「上游不支持 Responses」 
ProbeOpenAIAPIKeyResponsesSupport 的 2xx 分支靠「output 里有没有 function_call」
判定上游工具能力，但这只在响应真的跑完时成立。以下两种响应会被误判并落标：

- status=incomplete 且 incomplete_details.reason=max_output_tokens：探测请求自己
  只给了 512 的输出预算，推理型模型可能把预算全烧在 reasoning 上，还没轮到
  function_call 就被截断。
- status=failed：HTTP 200 携带的失败响应（上游瞬时故障）。

这个标记的代价很高：探测只在账号创建/更新时跑一次，写进
accounts.extra.openai_responses_supported 后不会自动重探，网关会长期把该账号的
/v1/responses 请求改走 /v1/chat/completions。对 Codex 客户端意味着 prompt 缓存
前缀被协议转换打散，issue #5371 实测缓存命中率从 ~85% 掉到 ~17%、成本涨 3.5 倍，
持续 32 小时无人察觉，最后是账号余额耗尽被停调度才自己弹回去。

同一个函数对非 2xx 早已写明「上游偶发故障不应误判为不支持」并保守返回 true，
2xx 分支缺的正是同一份保守。本次新增 responsesProbeVerdictIsConclusive：判据不
成立时保持 unknown 不写标记，与网络层失败、响应体读取失败的处理一致；网关按
「现状即证据」继续走 Responses。

status=completed 却只回 reasoning 的上游（火山方舟 coding/v3 × kimi-k2.6，即探测
最初要抓的目标）不受影响，仍落标为不支持。

另：落标为不支持时补一条 slog.Warn，让这次会长期改变成本结构的降级可被运维看到。

Fixes #5371
 2026-08-11 10:46:50 +08:00
li 12abb54700 fix(openai): 上游 HTML 403 不再被当成账号级错误处罚账号 
上游代理 / CDN 在请求到达 OpenAI API 之前拦下时，回的是 HTML 403 页面而不是
{"error":{...}} 结构化错误。这类响应描述的是「这条链路 / 这个端点被挡了」，
不构成账号凭据或权限失效的证据。

但 handleOpenAI403 不区分响应形态，一律按账号级 403 处理：

- 首次即 SetTempUnschedulable，账号 10 分钟不可调度；
- 连续 openAI403DisableThreshold(3) 次直接 SetError 永久禁用账号；
- 403 又在 failover 状态集里，同一个坏请求会被逐个账号重放。

结果是一个请求级错误被放大成整组账号下线。issue #5334 给出的触发方式是
POST /v1/responses/not-exist —— 该路径能通过只做结构校验的 guardResponsesSubpath，
转发后拿回 HTML 403，任何持有 API Key 的调用方重复几次即可打穿一个分组。
附带问题：整张 HTML 页面会被拼进账号错误信息写库并显示在管理端。

仓库对这类响应早有明确口径，只是没有应用到这条路径：

- openai_gateway_count_tokens.go 的 isOpenAIOAuthInputTokensUnsupported 已把
  「HTML 403 page without a structured error」按端点级响应处理；
- shouldApplyOpenAIAlphaSearchAccountErrorSideEffects 的既定不变式是
  端点级错误只换号、不写账号错误状态。

本次复用现成的 isHTMLResponse，在 handleOpenAI403 入口跳过账号处罚：不递增
连续 403 计数、不设临时不可调度、不永久禁用。failover 行为不变 —— 换一个走
不同代理的账号仍有可能成功。

Fixes #5334
 2026-08-11 10:18:20 +08:00
li 591d47fb9b fix(openai): 原生 Responses 路径不再把上游确定性 400 归一成可重试 502 
上游返回 400（invalid_function_parameters、missing_required_parameter 等）时，
`/v1/responses` 原生路径把它包成 `502 upstream_error / "Upstream request failed"`，
真实的 message/code/param 全部丢弃。

502 属于可重试类，下游网关会把这个永远不会成功的请求反复重放（issue #5479 实测
30 个失败请求被放大成 60 次上游调用），客户端也拿不到「哪个字段非法」的线索。

同一个 service 上的兄弟路径早已做对：
- `handleCompatErrorResponse`（ChatCompletions / Anthropic）回真实状态码 +
  invalid_request_error + 真实 message；
- `/v1/images/generations` 还额外透传 code/param。

原生 Responses 是唯一漏掉的一条，本次对齐。

改动只放行 400：走到该分支说明 `shouldFailoverOpenAIUpstreamResponse` 已判定这个
400 不可 failover，即 server_is_overloaded / at capacity 这类可重试的 400 不会到达。
401/402/403（运营方凭据问题）、404/405（可能是 base_url 配错）、429 一律维持原状。

Fixes #5479
 2026-08-10 11:25:46 +08:00
li 358e4a89a1 fix(openai-oauth): 个人订阅到期时间不再被 POID workspace 的 entitlement 覆盖 
enrichTokenInfo 里 plan_type 与 subscription_expires_at 的取值口径不一致：

- plan_type 有 shouldApplyChatGPTAccountInfoPlanType 护着（#3641），
  id_token 里的个人套餐优先，accounts/check 只在个人值为空时补位；
- subscription_expires_at 却是无条件覆盖。

accounts/check 是多账号/工作区端点，命中的记录由 access_token JWT 的 poid 决定。
当 poid 指向默认 Personal workspace、而 chatgpt_account_id 指向个人 ChatGPT 账号时
（两者是不同标识），拿到的 entitlement.expires_at 描述的是 workspace 权益。
配上被保护下来的个人 plan_type，账号页就显示成「个人 Pro + workspace 到期时间」。

代码里本来已经有正确的来源——用个人 chatgpt_account_id 查
/backend-api/subscriptions 的 active_until——但它被
`if TrimSpace(SubscriptionExpiresAt) == ""` 挡着，workspace 值一旦写进去就永远不触发。

改为让两个字段始终描述同一份订阅：

- 套餐取自 accounts/check 时（id_token 没带 chatgpt_plan_type），到期时间跟着取
  同一条记录，行为不变；
- 套餐保留了 id_token 的个人值时，只有该记录确实属于个人账号才用它的
  entitlement.expires_at；不属于就跳过，并强制回落到个人订阅端点。

为此给 ChatGPTAccountInfo 补 AccountID：优先读 account.account_id，缺失时退回
accounts 的 map key（key 可能是 "default" 这类别名）。两侧任一缺 ID 时判定为
无法区分并沿用旧行为，poid == chatgpt_account_id 的单人账号完全不受影响。

Fixes #5459
 2026-08-10 09:29:14 +08:00
li b6eb6c1efa fix(gemini): 原生生图按上游实际回吐的图片张数计费 
/v1beta/models/{model}:generateContent 与 Anthropic→Gemini 兼容路径的
ImageCount 只由 isImageGenerationModel(originalModel) 决定，而该白名单是
按 Google 官方模型名精确/前缀匹配写死的（antigravity_image_test.go 里
明确断言 my-gemini-3-pro-image-test 这类自定义名返回 false）。

GeminiMessagesCompatService 服务的却主要是 API Key + 自定义模型映射的账号：
客户端请求名和 GetMappedModel 后的上游名都可能是站长自取的别名，白名单必然
判不出来 → ImageCount=0 → calculateRecordUsageCost 里 `if result.ImageCount > 0`
的按次计费分支整条不触发 → 生图请求全部记 $0（issue #5358）。

改为优先按上游响应里真实的 inlineData 图片 part 计数：
- 新增请求级计数器，挂在 gin.Context 上，与既有的
  upstreamResponseModelObserver 同一批调用点取解包后的响应体；
- 取「单个 payload 内的最大值」而非累加：Gemini 兼容上游的 SSE 分片可能是
  累积式的（computeGeminiTextDelta 正是为此存在），逐 chunk 累加会把同一张图
  重复计费。max 保证累积式流与非流式都得到真实张数，增量式多图流最差退化到 1，
  与改动前同值，不构成回退；
- 每次 Forward 开头重置计数器，避免 failover 复用同一个 gin.Context 时
  把失败账号已回吐的图叠加到成功账号账单上；
- 响应里数不出图时（fileData 引用式回图等）退回原有模型名启发式，并额外认
  映射后的上游模型名，与 shouldSkipCodexPlanGatedImageModelCooldown 同时取
  requestedModel / modelKey 的口径一致。

inlineData / inline_data 两种字段风格都认（官方 SDK 与部分中转回 snake_case），
只统计带 base64 数据且 MIME 为图片的 part。

Fixes #5358
 2026-08-08 21:36:18 +08:00
li cbf2be05a3 fix(openai): 非流式生图脱钩上游 context，客户端断开不再导致图已出却不扣费 
forwardOpenAIImagesAPIKey 走的是 detachStreamUpstreamContext(ctx, parsed.Stream)，
该函数在非流式时原样返回请求 context（gateway_usage_billing.go:488）。于是客户端
中途断开会连带取消已经在出图的上游调用：上游那边图已生成并计费，网关这边拿到
context canceled，记 502，result 为 nil，handler 的 result.ImageCount > 0 兜底
无法命中，本次请求不产生扣费。

生图是长耗时（数十秒）且上游侧已产生实际成本的操作，与普通非流式 chat 不同：
提前取消并不能省下上游开销，只会丢掉已付费的产出。

同一端点的 OAuth 分支 forwardOpenAIImagesOAuth（openai_images_responses.go:1690）
以及同属媒体生成的 grok_media.go 本来就用无条件脱钩的 detachUpstreamContext，
OpenAI 网关侧 13 个转发点里只有这一处是例外。这里对齐。

Fixes #5411
 2026-08-08 15:24:34 +08:00
li 64090de664 fix(apicompat): Responses→Anthropic 转换不再发出上游会拒收的 content block 
convertResponsesInputToAnthropic 的 default 分支把未知 item 的 content 逐字
透传成 Anthropic user 消息，Responses 专有的分片类型会原样进入上游请求体。
最典型的是工具执行后回放的 reasoning item：带 content 数组时，reasoning_text
块直接发给 Anthropic，上游回 400 Request body format invalid，而该 item 会一直
留在会话历史里，导致此后每一轮都继续失败。

同时修正两处会产出空内容消息的路径——Anthropic 拒收空内容消息与空白 text 块：
分片全部不可识别时，user 消息退化成 content:""、assistant 消息退化成单个空
text 块。

改动：
- type=reasoning 显式跳过。Anthropic 无法摄入 OpenAI reasoning：encrypted_content
  不透明，thinking 重放需要上游签发的 signature。Codex 常见形态（只带 summary +
  encrypted_content）本来就会被丢弃，这里让带 content 的形态行为一致。
- default 分支改走 convertResponsesUserToAnthropicContent 白名单转换，保留其中
  可识别的文本/图片，丢弃其余分片。
- user / assistant 分支在转换结果为空内容或纯空白文本时跳过该消息。

Fixes #5329
 2026-08-07 23:09:03 +08:00
li 02fbcbe3ad fix(ratelimit): 守卫按端点来源门控，并与冷却键对齐模型口径 
上一版守卫只看模型类型，不区分请求从哪个端点进来。OAuth 账号的 /v1/images/*
上游同样是 Codex Responses（openai_images_responses.go → handleOpenAIImagesErrorResponse
→ handleOpenAIAccountUpstreamError → HandleUpstreamModelNotFound），所以专用生图
端点也会命中 plan-gated 分支。账号确实不具备生图能力时跳过冷却，会让调度层失去
唯一的刹车：每个请求都完整走一遍号池，对上游形成无上界的 400 放大。

改动：
- 新增 ctxkey.OpenAIImagesEndpoint 与 WithOpenAIImagesEndpoint /
  OpenAIImagesEndpointFromContext，在 handler/openai_images.go 入口置位；
  与 OpenAIImageGenerationIntent 区分——后者在 /v1/responses 带图片模型时也会置位。
- 守卫下移到 modelKey 计算之后，抽成 shouldSkipCodexPlanGatedImageModelCooldown，
  仅在 plan-gated 分支、且非 /v1/images/* 入站时生效。
- 同时判断 requestedModel 与最终 modelKey：冷却键走 account.GetMappedModel，
  账号可以把文本别名映射到 gpt-image-*，只判请求模型会漏掉这种形态。
 2026-08-07 20:49:39 +08:00
li b5d9fd21b0 fix(ratelimit): 图片模型被 Codex 文本端点拒绝时不再写模型冷却 
gpt-image-* 被误发到 /v1/chat/completions 或 /v1/responses 时，Codex 会稳定
返回 400 codex_plan_gated_model。HandleUpstreamModelNotFound 把它当成账号能力
缺失，给每个账号写 30 分钟 model_rate_limits 冷却。failover 走完整个号池后，
池内每个账号都冷却了该图片模型，于是后续走对端点的 /v1/images/generations
请求也一并 503 no available accounts。

在 codex plan-gated 分支里对图片模型提前返回：仍然 failover 掉本次尝试，
但跳过 SetModelRateLimit 写入，不把号池对正确的生图请求整体下线。

Fixes #4828
 2026-08-07 20:41:34 +08:00
li 146b8b6684 revert(grok): 撤回 405 账号级踢号，只保留 failover 分类 
tempUnscheduleGrok 是账号级、全端点、全模型的下线，而 handleGrokAccountUpstreamError
有 8 个调用点（raw chat / Grok 媒体 / CC 管线 / WS HTTP 桥接 / responses），
/v1/responses 的 405 只证明该端点缺失，账号在其他端点上仍然健康。

仓库里已有相反的既定不变式：shouldApplyOpenAIAlphaSearchAccountErrorSideEffects
把 404/405 显式排除在账号状态写入之外，注释写明「端点不存在只说明该上游不支持
独立搜索，账号本身健康」。

failover 分类器加 405 单独就能解开 sticky 锁死（调度器选号时会即时改绑 sticky），
账号级冷却不是必需的。「405 不踢号但记住端点能力」按端点级负缓存另行处理。
 2026-08-07 20:41:23 +08:00
li a071b27b41 fix(grok): 405 纳入 failover 与临时踢号，修复 Grok 会话粘性锁死 
Grok 分组里若有账号的自定义 base_url 只实现 /v1/chat/completions，对
/v1/responses 固定返回 405，会话 sticky 到该账号后就永久锁死：

1. shouldFailoverUpstreamError 不含 405，请求不进换号循环
2. handleGrokAccountUpstreamError 的 switch 不含 405，账号不进临时不可调度
3. 账号仍可调度，sticky 不清理，客户端自动重连继续绑同一个坏号

改动两处：
- shouldFailoverUpstreamError 增加 405，让请求可换号，sticky 随之更新
- handleGrokAccountUpstreamError 增加 405 → 30 分钟冷却，与 403 同级

Fixes #4668
 2026-08-07 20:37:56 +08:00
li 379db19141 perf(openai): 工具 Schema 净化改为单次拼接，去掉逐路径全量重写 
sjson.SetBytes 在 opts 为 nil 时 optimistic=false、inplace=false，每次调用都要
重扫整个文档并新建缓冲区拷贝，命中 N 处就是 N 次全量拷贝。/v1/responses 的 body
上限是 gateway.max_body_size（默认 256MB），构造请求能塞进百万级命中，会被放大
成 TB 级 memcpy。

改为收集 gjson 给出的绝对字节偏移后一次性拼接：全程一次分配、一次拷贝。
偏移不可用（Index 为 0）或与 body 对不上时跳过该处，而不是猜位置拼出损坏的 JSON。

实测（2000 处命中）：旧写法 17740 次分配，新写法 18 次。
 2026-08-07 20:37:44 +08:00
li f3c94d2099 fix(openai): 修正 Responses 工具 Schema 中显式为 null 的 parameters.type 
Codex Desktop 内置的 automation_update 工具会带 parameters.type = null，
OpenAI 直接回 400 invalid_function_parameters，而网关把该状态归一成可重试的
502 upstream_error。该工具定义还会沉进多轮会话历史，之后每一轮都继续失败，
同一份坏 Schema 在账号池里被反复重放。

在 OpenAIGatewayService.Forward 分流到 passthrough / Codex transform /
原生 ChatCompletions 之前，统一把显式为 null 的 parameters.type 补成
"object"，覆盖顶层 tools[] 与多轮历史里 input[].tools[] 的嵌套工具定义。

只修正显式 null：缺失 type 的 Schema 本身合法，补写会收窄客户端语义，
因此保持原样。

Fixes #5364
 2026-08-07 20:30:44 +08:00
li e687ca3e9d fix(ops): 系统日志落库失败后退避重试，避免拖垮数据库连接池 
OpsSystemLogSink 的 flush 没有任何失败退避：ticker 每 1 秒触发一次，每次都
带 5 秒超时打一批 COPY，失败后立刻在下一个 tick 再来一次。远程 PostgreSQL 上
COPY 被 context 取消会导致协议失步、连接被服务端 FATAL 终止，于是这条循环
变成持续的「占用连接 → 超时取消 → 销毁重建」；在 max_open 较小的连接池里，
日志通道会长期占满连接，业务侧最终报 Billing 503。

改为连续失败后指数退避（2s 起，翻倍，封顶 60s）：

- 退避窗口内直接丢弃当前批次并计入 dropped_count，不再触达数据库；
- 任意一次成功立即清空失败计数与抑制窗口；
- 失败日志随退避天然收敛为每个窗口至多一条，并附带 failures/backoff。

Fixes #5265
 2026-08-07 18:45:05 +08:00
li fe2c265c91 fix(identity): validate user-agent before persisting account fingerprint 
IdentityService 把客户端 User-Agent 作为账号级持久身份缓存（Redis
fingerprint:<accountID>），覆盖规则是"只升不降"的纯数值版本比较，且对 UA 内容
不做任何合法性校验：

- userAgentVersionRegex 不锚定，能从 claude-cli/999.0.0-local 解析出 999.0.0
- isNewerVersion 只比数值 + 产品名，999.0.0 恒大于任何真实版本
- fingerprintTTL 7 天配合每 24 小时懒续期，活跃账号上的指纹近乎永不过期
- IdentityCache 只有 Get/Set，管理端也没有重置入口

一个本地构建客户端发出 claude-cli/999.0.0-local 即可把账号身份永久钉死。此后
该账号所有上游请求在 HTTP 头与请求体 cc_version 两处都声称这个不存在的版本，
被上游判为非正版客户端并返回不带限流重置头的 429；无重置头又落到 5 秒兜底冷却，
账号池收缩后对外表现为 503 风暴。一条 failover 请求即可连带毒化多个账号——
指纹写入发生在上游调用之前，三次上游尝试全失败也照样毒化。

改动：

- 新增 isAcceptableFingerprintUserAgent，校验 <product>/<major>.<minor>.<patch>
  后必须紧跟空白或结束（拒绝 -local/-dev/+build 等本地构建后缀），并对 claude-cli
  的主版本号相对 claude.CLICurrentVersion 设上限（挡掉 999 这类哨兵版本）。
  非 claude-cli 产品只校验形态，避免误伤其他合法客户端。
- 创建与升级两条路径共用该校验。只在 isNewerVersion 处加校验不够：
  createFingerprintFromHeaders 首次创建时同样会原样保存畸形 UA，删键恢复后
  账号可被同一客户端立即再次毒化。
- 读取时自愈：缓存中已是畸形 UA 时（本次加固之前写入的），用本次请求的合法 UA
  或默认指纹替换并回写。否则存量已中招的账号仍然只能靠手工删 Redis 键恢复。
- 仅在真正阻止了一次写入时记录被拒 UA，便于定位污染源，同时避免被毒化客户端的
  高频重试刷屏。

Fixes #5254
 2026-08-06 15:01:28 +08:00
li e2652eb853 fix(billing): quantize usage billing amounts to the NUMERIC(20,8) scale 
同一笔 ActualCost 会被分别写入两条方向相反的 SQL：

    balance    = balance - $1      -- 存剩余额度，舍入的是"减法结果"
    quota_used = quota_used + $1   -- 存累计用量，舍入的是"加法结果"

两列都是 NUMERIC(20,8)，PostgreSQL 按 half-away-from-zero 舍入运算结果。
金额在第 9 位落到 half 边界时，两侧朝相反方向舍入：

    10 输入 token × 0.00000125 + 5 输出 token × 0.00001000 = 0.0000625
    × 1.25（分组倍率） = 0.000078125

    balance:    10000 - 0.000078125 = 9999.999921875 → 9999.99992188  delta 0.00007812
    quota_used:     0 + 0.000078125 =     0.000078125 →     0.00007813  delta 0.00007813

余额少扣、API Key 配额多记，单次相差 1e-8 且随请求量线性累积（1000 次 ≈ 1e-5 USD），
余额、Key 配额与用量记录无法精确对账，只能靠 epsilon 比较勉强吻合。

修复：在参数进入 SQL 之前，把命令中的全部金额统一量化到 8 位小数
（half-away-from-zero，与 PostgreSQL NUMERIC 一致）。两条语句拿到的是
同一个已落在 8 位刻度上的金额，存储阶段不再发生舍入，delta 精确相等。

- 走 shopspring/decimal 而非 math.Round(v*1e8)/1e8：后者在乘除中引入额外
  二进制误差，边界值可能被推到错误的一侧
- 量化排在指纹计算之后：指纹是请求幂等键，保持由原始金额派生，
  避免升级前后同一 request_id 的重试算出不同指纹而被判为 fingerprint conflict

Fixes #5229
 2026-08-03 20:00:32 +08:00
li 66ad405dd6 fix(upstream): set explicit TCP dial timeout on upstream transports 
http.Transport 未设置 DialContext 时使用零值 net.Dialer（Timeout=0），
DNS 解析与 TCP 握手没有任何上限，只能等内核 TCP 重传耗尽（Linux 约 130 秒）。
ResponseHeaderTimeout 只约束连接建立之后等待响应头的阶段，覆盖不到建连。

上游域名被解析到 443 不可达的 IP 时（DNS 污染 / 路由异常），单个账号就要卡满
内核超时；而多账号故障转移是串行的，一次请求会阻塞数分钟且不写中间错误，
客户端表现为"长时间无首字后直接结束"。

- buildUpstreamTransport 显式设置 DialContext（10s）与 TLSHandshakeTimeout（10s）
- proxyutil SOCKS5 分支的 forward dialer 由 proxy.Direct（零值 dialer，同样无超时）
  换成带 10s 超时的 net.Dialer；该分支会覆盖 Transport.DialContext，
  调用方设置的建连超时对它无效，必须在此补上

Fixes #5151
 2026-08-03 19:59:58 +08:00
li 3e26dfa5bb style: 统一 input 包装类型为 []any，与正常 OAuth 路径一致 2026-07-22 16:49:31 +08:00
li 851436c552 fix(openai): OAuth 透传路径补齐 input 规范化，修复 Input must be a list 
openai_passthrough=true 的 OAuth 账号透传路径
(normalizeOpenAIPassthroughOAuthBody) 未对 input 字段做
string→array 转换，导致上游拒绝 "Input must be a list"。

正常 OAuth 路径 (openai_codex_transform.go:290) 已有此逻辑，
透传路径遗漏。补齐三种非数组 input 的规范化：
- string → [{type:"message",role:"user",content:<text>}]
- 空白 string → []
- 单 object → [<object>]
 2026-07-22 16:46:29 +08:00
li 865128998c fix(billing): 合并 hosted image_generation 工具的图片 token 到 /responses 计费 
/v1/responses 端点使用 hosted image_generation 工具时，上游在
response.tool_usage.image_gen 返回图片 token 用量，但
extractOpenAIUsageFromJSONBytes 只读 response.usage，导致
image_output_tokens 和 image_output_cost 始终为 0。

在 extractOpenAIUsageFromJSONBytes 提取完 base usage 后，合并
tool_usage.image_gen 的 image tokens 维度（仅补充不覆盖），
覆盖 SSE 流式、非流式和 WebSocket 三条路径。
 2026-07-20 16:29:12 +08:00
li 72b29a7d4e fix(antigravity): 保留付费 tier 的 PlanType，IneligibleTiers 仅标记异常状态 
Fixes #4519
 2026-07-18 21:43:54 +08:00
li 7043982ae3 fix(grok): 纯客户端函数工具不再注入原生搜索工具 
Fixes #4486
 2026-07-17 16:59:40 +08:00
li 5fd030a01b test: 更新 image permission 测试适配 explicit intent 检查 
被动 namespace 不再触发 403，新增 PassiveNamespaceDoesNotTrigger403
测试和 OpenAI native/image model 的正向用例。
 2026-07-17 15:29:14 +08:00
li fc3c5a1e0c fix: 权限检查和并发槽也使用显式检查，修复被动 namespace 触发 403 
Fixes #4447
 2026-07-17 15:15:54 +08:00
li e375623abf fix(gateway): 被动 image_gen namespace 不再强制要求 Responses capability 
Fixes #4476
 2026-07-17 15:07:41 +08:00
li 288d3a1cce fix(frontend): saveS3Config 接入 step-up TOTP 门控 
Fixes #4445
 2026-07-17 14:52:54 +08:00
li 6a61b2daca fix(grok): 拦截图片模型发往 Responses 端点，返回明确错误 
Fixes #4301
 2026-07-15 11:16:07 +08:00
li 2e9b8d9a64 fix: resolve golangci-lint errcheck and gofmt violations in reasoning test 
Use two-value type assertions with require.True(t, ok) to satisfy
errcheck, and run gofmt to fix alignment.
 2026-07-14 13:23:57 +08:00
li ff639ba757 fix(grok): 清洗 reasoning 项中 content: null 避免 xAI 422 
Fixes #4237
 2026-07-14 13:13:32 +08:00
li 03ccb2a08e fix(payment): 删除泄露内部 AI 渠道配置的废弃接口 
Fixes #4160
 2026-07-13 15:22:39 +08:00
li b6427d4ec0 fix(apicompat): 流式 Anthropic max_tokens 映射为 incomplete + content_filter 映射为 finish_reason 2026-07-13 12:08:32 +08:00
li a5d40c9845 fix(apicompat): Read 工具参数实时流式发送，不再依赖 .done 事件 
Fixes #4114
 2026-07-13 11:47:18 +08:00
li bc3cb29027 fix(handler): 补齐 opsCaptureWriter 全部委托方法的 nil 守卫 2026-07-10 21:03:40 +08:00
li 89a551b964 fix(handler): opsCaptureWriter 释放后访问 nil panic 
Fixes #3961
 2026-07-10 20:56:31 +08:00
li 83f169e4fa fix(apicompat): 补齐 Responses→Anthropic 流式路径的 cache_creation_input_tokens 2026-07-10 20:49:44 +08:00
li 0d28f7f90d fix(apicompat): Responses↔Anthropic 转换补齐 cache_creation_input_tokens 
Fixes #3935
 2026-07-10 20:40:45 +08:00
li ea9f40b63f fix(frontend): UserBreakdownParams.request_type 类型从 number 改为 UsageRequestType 2026-07-10 12:38:21 +08:00
li b9b013a088 fix(usage): WS passthrough effort 提取补入映射后模型候选 
Fixes #3924
 2026-07-10 11:56:47 +08:00
li dda8f78733 fix(admin): GetUserBreakdown 使用 ParseUsageRequestType 解析 request_type 
Fixes #3920
 2026-07-10 11:43:44 +08:00
li e984b4e2e1 fix(i18n): 补齐 en 语言包 overview 和 resources 缺失 key 
Fixes #3909
 2026-07-10 10:45:44 +08:00
li 657c4f97d9 fix(openai): 升级 Codex 客户端版本至 0.144.1，修复 gpt-5.6-luna 404 
Fixes #3895
 2026-07-10 09:56:33 +08:00
li 8f97953e51 fix(gateway): SSE response.failed 应用错误透传规则，不再硬编码 502 
Fixes #3857
 2026-07-09 18:09:37 +08:00
li 15c59be787 fix(frontend): 补齐 en 语言包缺失 key 并对 site_logo 统一应用 sanitizeUrl 2026-07-09 17:22:04 +08:00
li 104fd2b6ec fix(messages): /v1/messages 非 cyber response.failed 补全 failover 和错误回写 2026-07-09 16:49:13 +08:00
li 7468427e44 fix(messages): /v1/messages 传输层错误对齐 failover 链路，不再直接 502 
Fixes #3850 (part 2)
 2026-07-09 15:49:10 +08:00
li 1785509873 fix(apicompat): ResponsesToAnthropicRequest 补全 instructions 字段并映射 developer role 
Fixes #3850
 2026-07-09 15:34:10 +08:00
li bfb827b879 fix(security): HTML-escape site_name 并对 doc_url 统一应用 sanitizeUrl 
Refs #3839 (第 8、12 点)
 2026-07-09 10:03:49 +08:00
li 2dd2be9922 fix(compact): 识别 /v1/responses body 中的 compaction_trigger 信号 
Codex remote compact v2 可以把 compact 触发器作为 input item
（type=compaction_trigger）嵌入普通 POST /v1/responses 请求体，
而非直接调用 /v1/responses/compact。此前 isCompactRequest 仅检查
URL path 后缀，导致 body-signal 形式的 compact 请求被当作普通
Responses 处理——上游路径、模型映射、body 归一化全部错误，Codex
收到非 compact 响应后报 "expected exactly one compaction output
item, got 0"，长会话无法继续。

新增 hasCompactionTriggerInInput 检测 input 中的 compaction_trigger
item，命中后提升为 compact 请求并改写 URL path，使后续所有
isCompactRequest 分支（模型映射、body 归一化、上游 URL 构建）
自动生效。

Fixes #3777 (part 1: body-signal routing)
 2026-07-07 21:23:02 +08:00
li a86c534cb0 test: 补充侧边栏滚动位置持久化的前端测试 
- AppSidebar.spec.ts：验证 template ref 绑定、sidebarNavRef 声明、
  onBeforeUnmount 保存 scrollTop、onMounted 恢复
- app.spec.ts：验证 sidebarScrollTop 默认值为 0 且可读写
 2026-07-07 21:11:40 +08:00
li c7e44a83ad fix(frontend): 路由切换后保持侧边栏滚动位置 
AppLayout 在每个页面组件内部包裹，路由切换时整个组件树（含
AppSidebar）被销毁重建，侧边栏滚动位置丢失。管理员菜单较长
或屏幕较矮时，每次点击靠下的菜单项后都要重新滚动。

在 appStore 增加 sidebarScrollTop 状态，AppSidebar 在
onBeforeUnmount 保存、onMounted 恢复滚动位置。

Fixes #3796
 2026-07-07 21:08:03 +08:00
li 69d02d2036 fix: 补齐 failover 路径的 appendOpsUpstreamError 日志 
审查发现 error 路径缺少 appendOpsUpstreamError 和 upstreamDetail
记录，与 forwardResponsesViaRawChatCompletions 不对称。
 2026-07-07 17:35:09 +08:00
li 5c0e580fbe fix(messages): /v1/messages 入站支持不兼容 Responses API 的 OpenAI 上游 
ForwardAsAnthropic 此前无条件把 Anthropic Messages 转为 Responses
格式发往 /v1/responses，导致只支持 /v1/chat/completions 的第三方
OpenAI 兼容上游（京东云、DeepSeek、Kimi、GLM 等）全部 400。

在入口增加与 ForwardAsChatCompletions 对称的 ShouldUseResponsesAPI
分流：APIKey 账号 + 上游不支持 Responses 时，改走新建的
forwardAnthropicViaRawChatCompletions，链式复用全部已有转换桥
（Anthropic→Responses→CC 请求，CC→Responses→Anthropic 响应），
不新建转换函数。

Fixes #3735
 2026-07-07 17:23:18 +08:00
li a02700c16f fix(image): 识别 Codex namespace image_gen 工具声明以拦截生图请求 
分组 allow_image_generation=false 时，Codex /image 技能通过
namespace 工具声明（type=namespace, name=image_gen）和 Responses
Lite 的 input additional_tools 绕过了现有生图意图检测——现有逻辑
只识别 tools[].type == "image_generation" 这一种形式。

在 gjson 版（openAIJSONToolsContainImageGeneration）和 map 版
（hasOpenAIImageGenerationTool）检测中增加 namespace image_gen
识别；同时扫描 input[].type == "additional_tools" 中嵌套的工具
声明，覆盖 Responses Lite 格式。

Fixes #3608
 2026-07-07 16:58:48 +08:00
li fd64d07e61 fix(codex): 剥离续链 function_call item 的非法 item_* id 
OpenAI OAuth 转发续链请求时，function_call 等 call-input 类 item 的
id 被客户端以 item_* 形式回放，但上游要求以 fc 开头，返回 400
"Expected an ID that begins with 'fc'"，导致工具续链反复失败。

filterCodexInputWithOptions 在 PreserveReferences=true 路径下对
call-input 类 item（function_call/tool_call/local_shell_call 等）
增加 id 前缀检查：非 fc 开头即删除。output 类（function_call_output
等）的 id 无此约束，不动。

Fixes #3785
 2026-07-07 15:54:55 +08:00
li fa01aec80d fix: 前缀全部加连字符，与 thinking_protocol.go 风格对齐 
deepseek → deepseek-、moonshot → moonshot-、qwen → qwen-/qwen2-/qwen3-/qwen4-、
minimax → minimax-、llama → llama-/llama2-/llama3-、mistral → mistral-、
mixtral → mixtral-。避免无连字符前缀误伤假想的连写模型名。
 2026-07-07 15:00:00 +08:00
li 9b75c7b76c fix(scheduler): 改用异族厂商前缀黑名单，兼容渠道级模型映射 
自审发现白名单守卫有误伤面：渠道级模型映射在账号选定之后才改写
请求体模型名，调度过滤看到的是改写前的原始别名。若按 Codex 白名单
判定，「渠道映射自定义别名 → gpt-5.x + 空映射 OAuth 账号」的既有
部署会被误判为 model_not_found。

改为保守 fail-open 黑名单：空映射默认仍允许，仅排除 deepseek/glm/
kimi/qwen/gemini/grok 等明确异族厂商前缀（Codex 上游绝无可能服务，
透传必然换来不可重试 400）。前缀分类先例见 ResolveThinkingProtocol。
 2026-07-07 14:19:58 +08:00
li 2a3dcb499f fix(scheduler): 空 model_mapping 的 OpenAI OAuth 账号不再吸收全部模型 
空映射此前一律视为「允许所有」，导致混合部署下请求非 OpenAI 模型
别名（deepseek-v4 等）时，OAuth 账号可能被调度选中；转发阶段对未知
模型原样透传，Codex 上游返回不可重试的 400，请求无法 failover 到
真正支持该模型的 API Key 账号。

IsModelSupported 对空映射的 OpenAI OAuth（未开透传）账号改为与转发
归一化对齐的判定 isOpenAIOAuthServableModel：可归一到已知 Codex 模型
集合（含 gpt-image-*、推理后缀、别名拼写）或 claude-* dispatch 系列
才视为可服务。API Key/显式映射/透传/其他平台语义不变。

Fixes #3662
 2026-07-07 14:06:21 +08:00
li 40c563c4ae fix(gateway): 记录请求体解析失败的真实原因，不再吞错 
400 "Failed to parse request body" 此前丢弃底层错误，无法区分
JSON 真非法、还是 body 被截断/被中间件提前消费。

- 服务层 invalid json 错误增补 len/offset/非法字符信息
  （仅诊断元数据，不含 body 内容，可安全 wrap）；
- handler 层新增 logRequestBodyParseFailure，向服务端日志输出
  底层错误 + body 长度 + 转义后的 head/tail 片段（各 256B），
  客户端响应文案保持不变；
- 接入全部 9 处入站解析点（messages/count_tokens/responses/
  chat_completions/embeddings，Anthropic 与 OpenAI 网关）。

Fixes #3715
 2026-07-07 13:53:39 +08:00
li 867616fca8 fix(websearch): 剥离历史消息中上游不接受的 web search 块 
Web Search 模拟合成的 server_tool_use / web_search_tool_result 块
（srvtoolu_ws_ 前缀）被客户端回传到后续 /v1/messages 历史后，
上游一律 400（GLM 等第三方兼容上游只接受
text/thinking/image/tool_use/tool_result），会话从此卡死。

新增 FilterWebSearchHistoryBlocks 预过滤：
- 模拟伪造块对所有上游无条件剥离；
- 真实 web search 块仅对 passback-required 协议族剥离
  （复用 ResolveThinkingProtocol），不误伤官方 Anthropic 会话；
- 接入 Anthropic 通用转发与 API Key 透传两条路径的既有 pre-filter 区。

Fixes #3677
 2026-07-07 13:41:40 +08:00