builder 里一次 panic 会把传输缓存锁到重启：v8.0.51 还坏着的三处，与只落在 dev 的修复
CLIProxyAPI 的四笔修复挤在 13 秒里并进了 dev，v8.0.51 一笔都没带；这篇把三个「现在的版本上还坏着」的坏法、判据与处置一次讲清，另外说清那个看着要你重新授权的 Antigravity scope 为什么现在用不上。
窗口 11-02 17:17–18:11（北京时间）｜本期只有一件事要判断：现在跑的这一版要不要动。
这一小时里 CLIProxyAPI 的开发分支收了四笔，v8.0.51 一笔都没带。
发行版是今天凌晨 1:07 发的，此后主干没有再动1。
四笔合并集中在前后十一分钟：三笔挤在 13 秒里，第四笔在 18:04 收尾。
其中三笔来自同一位贡献者开出的报障；他开的第四张单，对应的补丁还在评审。
结论很短：今晚不用升版本。但你得认得出下面这三种坏法，否则在 v8.0.51 上遇到它们，会误判成上游抽风。
先看这张表
| 编号 | 作者 | 合并（北京） | 一行说明 | v8.0.51 含不含 |
|---|---|---|---|---|
| #7164 | sususu98 | 17:52:56 | builder panic 时释放传输缓存的锁 | 不含 |
| #7165 | sususu98 | 17:53:02 | 凭据去重键纳入 connection-pool | 不含 |
| #7166 | sususu98 | 17:53:09 | handler panic 时也把请求日志收尾 | 不含 |
| #6315 | SomSamantray | 18:04:08 | Antigravity OAuth 增加 aicode scope | 不含 |
| #7167 | sususu98 | 未合并 | pluginhost 模型流归属 | 不含 |
| #7199 | shoucandanghehe | 未合并 | 大 Responses 请求少拷几份内存 | 不含 |
还有一句提醒：那三张报障本身仍然开着。单子没关不等于没修，这一次就正好反过来。
坏法一：build() 里一次 panic，这张缓存从此拿不到锁
一句话：panic 跳过了解锁语句，而这把锁没有兜底。
v8.0.51 的
Get 在 111 行 c.mu.Lock()，直到 119 行才调 build()；三条返回路径各自手写 c.mu.Unlock()（115、121、125 行），中间没有 defer。
gin 的 recovery 会把进程留住，返回一个 500，进程继续跑。于是这把锁永久不放开。
谁会踩到：走代理或连接池的请求（
proxy_helpers.go 296 行，缓存容量 512），Devin 执行器（同文件 525、546 行），以及 Antigravity 执行器——它每个请求都过这张缓存（antigravity_executor.go 337、371 行）78。现场判据：进程活着、CPU 很低，这几类请求既不返回也不报错，goroutine 数只涨不降。
处置只有重启——缓存本身没有恢复路径，它不会自己把锁放开。
坏法二：handler panic 一次，这条请求的日志永远不写
一句话：日志中间件在 recovery 里面，panic 直接越过了它。
v8.0.51 的
internal/api/server.go 里，GinLogrusRecovery() 注册在 174 行，RequestLoggingMiddleware 在 190 行10。panic 从 handler 抛出一路向外，
request_logging.go 90 行的 c.Next() 不会正常返回，它后面那句平铺的 wrapper.Finalize(c)（93 行）就没机会执行11。
http.ErrAbortHandler、正文没写过就补 500、调 Finalize，最后把 panic 原样抛回去（106–108 行），交给外层 recovery 处理。12后果不止少一条日志。流式响应那个 writer 的 Close 也走不到，每 panic 一次就漏一个文件句柄和一条 goroutine。
请求体是延迟落盘的，临时目录建在日志目录下（
request_logger_body_source.go 32 行，request-log-parts-request-body-*），收不了尾就会留在磁盘上13。现场判据三条：
recovered from panic 的日志条数（gin_logger.go 145 行）与缺失的请求日志条数对得上；日志目录里堆着 request-log-parts-request-body-*；文件句柄与 goroutine 随 panic 次数往上走14。修法两步，缺一不可：日志中间件自己加 defer 收尾；同时把 recovery 挪到日志之后（dev 在 196 行）。只做前一步，日志的时序还是反的。
坏法三：只差 connection-pool 的两张凭据被合成一张
一句话：去重键里没有连接池设置，两条不同的配置被判成同一条。
老的键由五项拼成：api key、base url、proxy url、prefix、排好序的 headers。dev 在末尾加了第六项。
formatGeminiKeyDedupID：427–436 行还是原来那五项，437 行新增 FormatConnectionPoolDedupID(entry.ConnectionPool)，443 行起是这个新函数。15新函数把连接池的 enabled、空闲超时、每主机最大空闲连接数串进键里。同一版里，vertex-compat 的去重键也一起改了16。
后果是最难查的那种：被吞掉的那条既不报错也不打日志，磁盘上的配置文件与内存里的配置不一致。报障人写的正是这一条——两条只差
connection-pool 的 key，最后只剩下一条17。升级后还有两件可预期的事
第一件：之前被吞掉的条目会回来，号数会变多。别当成重复导入又删一遍。
第二件：配了
connection-pool 的凭据，auth_index 会重算。dev 的 indexSeed() 把连接池的 seed 拼进了 seed，已有 Index 的沿用旧值。
seed += "\x00" + poolSeed——这就是「auth_index 会变」的唯一出处；没配 connection-pool 的凭据这个分支不成立。18所以升级前先存一份凭据清单，升完对比：
curl -s -H "Authorization: Bearer $SECRET" \
http://127.0.0.1:8317/v8/management/credentials \
| jq -r '.files[].auth_index' | sort > before.txt差出来的那些，就是配了 connection-pool 的凭据。写死 auth_index 的脚本、看板、告警规则都要跟着改。
Antigravity 的 aicode scope：加了，但现在没地方用
#6315 只改了一行字符串：
internal/auth/antigravity/constants.go 里的 scope 列表多了一个 aicode。我把 dev 整包搜了一遍：仓库里没有任何对
aicode.googleapis.com 的调用。v8.0.51 的同名文件是 0 命中。PR 正文自己写着「现有凭据可能需要重新登录 Antigravity，才能拿到这个 scope」。它关的来源单是 #5289，讲的是 agy 1.1.22 的语音转写与 gemini-3.5-transcribe19。
所以重新授权这件事，现在只是为将来的语音转写铺路，不解决你手上的任何报错。别做批量重授权。
sub2api：空流立即换号这条路被判死
维护者在 17:45:56 关了 #7751，理由是「反思之后，这条不是对的修法」。
原话："On reflection, switching accounts immediately on an empty malformed stream (the approach in #7753, now closed) isn't the right fix; #7899 instead treats terminal empty streams as a normal finish and limits retries to the same account without unscheduling it."20
closed this as not planned（17:46:01）：换号方案 #7753 已关，#7751 改指 #7895 / #7899。21对应的补丁 #7753 在 17:35:02 关闭，没有合并22。
但这里有一处口径打架，必须点出来。
维护者说 #7899 不换号；#7899 自己的说明写着「不替代 #7753，换号那部分仍归它」，还写着「本分支让这类包继续走既有的空流换号路径」23。
两边相反。落地之前别按任何一个口径排产，等它合了直接读代码24。
现场含义先记一条：终态空流可能被当成正常结束。客户端要自己识别空回合——
content 为空、token 计数可能也没有——别当成功入库。同一条线上还有一张挂着：前两期写过的 #8481（流式里
server_is_overloaded 不触发已配置的模型级临时不可调度）窗口内仍无回复、无补丁，维护口径未定25。还没合并的那张：150 MiB 内联图，v8.0.50 上存活堆 632 MiB
#7199 今天 17:29:50 开出，目前 open、mergeable clean，13 个文件 +288/−40、4 个提交26。
作者给的压测是同一套本地 HTTP/SSE 探针、同一张合成的 150 MiB 内联图，基线取 v8.0.50：存活堆 632 MiB，四个提交后 482 MiB；累计分配 4,443 MiB 降到 2,193 MiB。
运维含义：大图、长上下文这类请求，内存按两倍余量规划。但这条还没合并，今晚别指望它缓解。
行情
四仓版本没动：CLIProxyAPI v8.0.51、sub2api v0.2.19、codex-proxy v2.1.21、codex2api v3.1.2。
上游三处状态页窗口内全绿：OpenAI 零降级组件，最近一条事件 10-30 已恢复27；Anthropic 最近事件 10-28 恢复28；Google Cloud 八条，最新更新停在 10-2829。
codex-reset 的读数：今天 UTC 还没重置，最近一次已验证的重置在 10-28 早 6:35（UTC），累计 61 次、10 次 banked，节奏约每两天一次30。
社区一侧：OpenAI 开发者论坛 Codex 分区窗口内两条新帖，都是产品建议，没有额度信号31。
顺带一句状态更新：前几期写过的 #7186（Gemini 的 role 改写）在 17:43:35 关成 completed32。
今晚能做的三件事
一，把三种坏法的判据抄进值班手册：请求挂住先看 goroutine 是不是只涨不降；日志缺条先数
recovered from panic 与残留临时目录；号少了先对 auth_index。二，别急着给 Antigravity 重新授权。这笔补丁现在没有调用点。
三，别按空流换号排产。两个口径还打着架，等它落地。
下一版发行时，前两笔修复会随版本到；第三笔（凭据去重）要留意号数变多与 auth_index 变化，那都是预期的。
References
- 1CLIProxyAPI Releases
github.com
- 2PR #7164
github.com
- 3PR #7165
github.com
- 4PR #7166
github.com
- 5PR #6315
github.com
- 6transport_cache.go@v8.0.51 L102-L127
github.com
- 7proxy_helpers.go@v8.0.51
github.com
- 8antigravity_executor.go@v8.0.51
github.com
- 9transport_cache.go@dev L108-L126
github.com
- 10server.go@v8.0.51 L168-L196
github.com
- 11request_logging.go@v8.0.51 L86-L96
github.com
- 12request_logging.go@dev L87-L119
github.com
- 13request_logger_body_source.go@v8.0.51
github.com
- 14gin_logger.go@v8.0.51
github.com
- 15config_normalization.go@dev L424-L448
github.com
- 16vertex_compat.go@dev
github.com
- 17Issue #7163
github.com
- 18types.go@dev L693-L707
github.com
- 19Issue #5289
github.com
- 20Issue #7751
github.com
- 21Issue #7751 closed as not planned
github.com
- 22PR #7753
github.com
- 23PR #7899
github.com
- 24PR #7895
github.com
- 25Issue #8481
github.com
- 26PR #7199
github.com
- 27OpenAI Status
status.openai.com
- 28Anthropic Status
status.anthropic.com
- 29Google Cloud Status
status.cloud.google.com
- 30codex-reset
codex-reset.com
- 31community topic 1411969
community.openai.com
- 32Issue #7186
github.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.