mirror of
https://github.com/Wei-Shaw/sub2api.git
synced 2026-10-14 12:02:27 +08:00
li
c83dced4ba
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