两条只差连接池的 Gemini 凭据，第二条被静默丢掉
下一版会把两条只差连接池设置的 Gemini / Vertex 凭据判成同一条、静默丢掉第二条；同一小时冒出的另外四张单在 v8.0.49 里都存在，三张补丁都还没合。
北京时间 18:06 到 20:15，四个仓库都没有发版：CLIProxyAPI 仍是 v8.0.49，sub2api 仍是 0.2.19，codex-proxy 停在 v2.1.21，codex2api 停在 v3.1.2。12
这两小时里 CLIProxyAPI 新开五张单、跟了三张补丁，全部出自同一位报障人。开发分支只多了一笔改注释的提交。3
先说结论
五张单里最关键的一张，只在开发分支上成立：两条只差
connection-pool 设置的 Gemini 凭据会被判成同一条，第二条连同它的池设置一起消失，没有日志。4今天跑 v8.0.49 的人不会踩这条，因为发行版里那个池字段还不存在。麻烦的是另外四张，它们在 v8.0.49 里一行不少。
| 单号 | 现象 | v8.0.49 里有吗 | 补丁 |
|---|---|---|---|
| #7163 | 去重身份不含连接池，第二条凭据被静默丢弃 | 只在开发分支 | #7165，未合并 |
| #7159 | 插件能读走并关掉别人的模型执行流 | 有 | 无 |
| #7162 | 传输缓存构建时 panic，缓存永久锁死 | 有 | #7164，未合并 |
| #7161 | handler panic 后请求日志永不收尾 | 有 | #7166，未合并 |
| #7160 | 运行时改 auth-dir，监控还盯旧目录 | 有 | 无 |
三张补丁都还是 open，一张都没合。所以今晚能做的不是升级，是知道自己手上是哪一种。
去重身份里缺的那一项
凭据列表进内存前会过一道清洗：逐条裁字段，再用一个唯一键去重。5
唯一键由五项拼成：api-key、base-url、proxy-url、prefix、排好序的 headers。函数上方的注释也是这么写的，五项之外没有别的。
config_normalization.go 第 400–436 行：唯一键按 api-key、base-url、proxy-url、prefix、headers 顺序拼接；命中即 continue，后出现的那条被丢掉，全程无日志。5
config_types.go 第 912–940 行：ConnectionPool 字段就在 ProxyURL 之后，注释写明按凭证隔离；而上面的唯一键里没有它。6于是一个块写了
max-idle-conns-per-host: 2、另一个写 5，其余全同的两条，被判成同一把凭据。第二条不进内存，池设置也就不存在。先出现的留下，后出现的消失。这是去重循环的写法决定的，不是配置合并的副作用。7
Vertex 那条更省事，唯一键直接是 api-key 加竖线加 base-url，池字段同样没进去。8
为什么发行版今天不踩
去重代码本身两版逐字节相同。也就是说这道清洗一直只看五项，只是在发行版里，这五项恰好就是全部可配项，没有信息可丢。
按 key 的连接池是随 PR #7101 进开发分支的，上期已经写过它没进 v8.0.49。10 池先到、去重键没跟上，这条缺陷就是下一版带出来的。
所以判断句很短：发行版不丢，开发分支与下一个发行版会丢。
什么时候当场就丢
清洗不只跑在启动。加载配置时会调一次，两条解析路径各调一次。11
管理端写凭据列表的入口也各调一次，六个位置都在同一个文件里。12
意思是：你不用等重启。通过管理端把两条只差池设置的条目推上去，响应是 200，磁盘写进去了，内存里只剩一条。
自查与处置
先说一个容易走错的方向：管理端读回配置的那个接口，读的是磁盘文件，不是内存。13
所以它会照原样把两条显示给你。看着对，运行时并不是那样——这恰恰是「磁盘与内存不一致」的证据，而不是反证。
真正能自查的动作是数条目：磁盘 yaml 里 api-key 与 base-url 都相同的 gemini-api-key、vertex-compat-api-key 各有几组。每组只有第一条的池设置会生效。
处置只有一条干净的：把两条并成一条，池设置写在留下的那条上。真要两条并存，等 #7165 合并——它把连接池加进了两处唯一键，还带了回归测试。14
别用改 prefix 或加 header 去凑出不同身份。那两项本来就在唯一键里，凑是能凑开，但前者会改模型命名空间、后者会给上游多发一个头。
同一批的另外四张单
这四张在 v8.0.49 里都存在，且都没有补丁或补丁没合并。
插件能读走别人的模型执行流。 桥在开流时记下了属主，但读取和关闭两个方法都只收流 id，属主从头到尾没被比对过。15
model_stream_bridge.go 第 40–88 行：read(ctx, id) 与 close(id) 的签名里没有调用方身份；ownerCallbackID 只写进条目，没有任何一处读它比对。16流 id 是进程内自增计数，1、2、3，猜得出来。发行版里这个文件与开发分支逐字节相同。
后果不用夸大：只有当你在同一个进程里装了多个插件、且它们不互相信任时，才构成问题。同一位报障人的实测是读到了别人的响应块，并把那条流关掉了。
传输缓存 panic 后永久锁死。
Get 先拿锁，再调外来的构建函数，所有返回路径手写解锁。构建函数一 panic，解锁那几行都走不到。17
transport_cache.go 第 103–147 行：c.mu.Lock() 在 build() 之前，之后每个出口都是显式 Unlock；没有 defer，也没有 recover。18这条的后果是进程级的：之后所有需要 transport 的请求都卡在同一把锁上，
TryLock 也拿不到。发行版同一段代码也是这个写法。19handler panic 后请求日志不收尾。
c.Next() 跑完才调收尾，而不是 defer；recovery 中间件注册在更外层。20
request_logging.go 第 80–100 行（v8.0.49）：第 90 行 c.Next()，第 93 行才是 wrapper.Finalize(c)；handler panic 会绕过这一行，外层 recovery 收走控制权。21每次被 recover 的 panic，泄漏一个流式日志 writer 和它打开的文件。次数少看不出，次数多的进程迟早撞到句柄上限。
运行时改 auth-dir 不生效。 监控对象在创建时把目录固定下来了，换配置只换了配置本体，目录字段不动。22
现象是：把
oauth.auth-dir 从 A 改到 B，返回 200、重载日志也写了 A 到 B，但凭据列表仍是 A 的，B 里的文件永远不出现，往 A 里写新文件却被正常发现。23这条没有补丁，处置只有一个字：重启。
今晚三步
- 跑 v8.0.49 的：四条现网行为都不用改配置。要记住的是 panic 之后只能重启复位，别指望它自己好；别把互不信任的插件塞进同一个进程。
- 从开发分支构建的：写 gemini-api-key 或 vertex-compat-api-key 之前先数条目。两条只差池设置的，先并成一条再上线。
- 改过 auth-dir 的：改完重启，然后用凭据列表核一遍，别只看那行日志。
另外几个仓库
sub2api 这一窗口没有新条目，只有那条四月开的交流长帖被顶起来一次。26 codex-proxy 零条目。
codex2api 一开一关。新开的是密钥自助页的并发与请求日志展示，open。27
关掉的那条更值得看一眼：报障说官方价目同步会把缓存读取价与输出价写反，用另一家数据源则不会，18:38（北京）关成已完成。28
如果你用它的官方价目同步，去对一眼价目表里缓存读取与输出两列。v3.1.2 是 10 月 27 日发的，修复落在哪一版我没核出来，别默认手上这份已经带着。
上游与社区
r/OpenAI 这一小时冒出一条帖子，转述了一段通知原文：ChatGPT 与 Codex 将在未来几周共用同一份额度，用量按模型与任务复杂度计，Unlimited Instant 不计入。29
同一段文字在 r/codex 与 Hacker News 上也有人贴。30 截至发稿，官方页面没有找到同文，这条按未证实记，别当结论用。
对中转的含义倒是清楚：如果落地，ChatGPT OAuth 账号的 Codex 额度会与这个账号在别处的使用互相消耗。到那时再调池子，不如现在就把额度读数按账号算，而不是按请求算。
重置这边没有新动作。今天 UTC 还没重置，最近一次已验证的全局重置仍是 10 月 28 日 06:35（北京 14:35）。31 10 月 31 日 19:59 到账的那枚 banked 仍记在账上。
三家状态页这一窗口都安静：OpenAI 全绿，32 Anthropic 最近一条是 10 月 28 日的日历连接器事件、已解决，33 Google Cloud 八条、最新停在 10 月 28 日。34
上期在跟的几条
CLIProxyAPI #7156 仍 open、未合并；#7154 与 #7151 形态未变。35
顺带一提，这五张单的报障人同一小时还往开发分支推了一笔只改注释的提交，讲的是连接池在保存时的裁剪边界，明确写了没有行为变更。36 他在这块贴得很近，下一版的动静值得跟着看。
References
- 1CLIProxyAPI v8.0.49
github.com
- 2sub2api 0.2.19
github.com
- 3CLIProxyAPI 窗口内条目
github.com
- 4issue #7163
github.com
- 5config_normalization.go
github.com
- 6GeminiKey 结构体
github.com
- 7去重循环
github.com
- 8vertex 条目去重
github.com
- 9v8.0.49 的 GeminiKey
github.com
- 10PR #7101
github.com
- 11加载期的清洗调用
github.com
- 12列表写入时的清洗
github.com
- 13GET 读磁盘
github.com
- 14PR #7165
github.com
- 15issue #7159
github.com
- 16model_stream_bridge.go
github.com
- 17issue #7162
github.com
- 18TransportCache.Get
github.com
- 19v8.0.49 的同一段
github.com
- 20issue #7161
github.com
- 21request_logging.go
github.com
- 22issue #7160
github.com
- 23watcher 构造与 SetConfig
github.com
- 24PR #7164
github.com
- 25PR #7166
github.com
- 26sub2api 旧帖 #764
github.com
- 27codex2api #847
github.com
- 28codex2api #835
github.com
- 29r/OpenAI 帖
reddit.com
- 30r/codex 同文帖
reddit.com
- 31codex-reset
codex-reset.com
- 32OpenAI 状态页
status.openai.com
- 33Anthropic 状态页
status.anthropic.com
- 34Google Cloud 状态页
status.cloud.google.com
- 35PR #7156
github.com
- 36提交 a21814ec
github.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.