生产栈落在一处裸读上，两张补丁只锁住了 Claude
CLIProxyAPI 一处凭证 metadata 的裸读被一条带栈的生产崩溃报告追上，而两张在评审的补丁只锁住了 Claude 那几处；另附 sub2api 缓解 overload 的改动已进 main 未发版、codex2api 拒收 configuration_update 的现状与处置。
北京时间 13:18，CLIProxyAPI 那张修 metadata 无锁读的 PR 下面来了一条带栈的评论：一个自建实例在 antigravity 的 Gemini 路径上崩了。1
上一期我给的限定是「只有把执行器嵌进自己服务的才够得着」。这条评论把那个限定推开了半步。
在那条评论之前二十分钟，作者已经开了第二张补丁 #6909，只把 Claude 那四个调用点包进锁里。两张单加起来，仍然没碰到栈上那两个通用读函数。
窗口是北京 12:58 到 13:56。四个仓库零新版本，CLIProxyAPI 的 dev 头也停在窗口之前。
一、栈上的六层，五层与今天这版逐行对上
报障人 yanhao98 给的栈是六层：
strings.go:1093、classification.go:147、conductor_refresh.go:402、conductor_refresh.go:412、types.go:1107、selector.go:833。1翻成动作只有一句：选号循环在判断一个候选凭证还能不能用时，顺手读了一次它的 access token；读的时候，另一个 goroutine 正在写同一张 map。
sdk/cliproxy/auth/classification.go 第 113–151 行：上半段 authHasOAuthMetadata 逐个 key 调 authMetadataString，下半段第 141 行的函数体内，第 145 行是一次裸的下标读取，第 147 行才做 TrimSpace；整个文件里这条路径没有任何互斥。(classification.go) 也就是说，每挑一次凭证、每看一个候选，都会在锁外面读一次它的令牌。
六层里四层与今天这版逐行对上（
strings.go 那层取决于编译时的 Go 版本）。对不上的是 HasValidAccessToken：它在报障人的二进制里位于 types.go:1107，而 v8.0.40 的这个函数在第 1187 行、v8.0.39 在 1126 行、v8.0.38 在 1103 行。6他自己的构建比今天这版旧一些。但四层逐行对得上说明一件事：这处裸读不是老版本的遗留，今天这版原样还在。
二、写侧落在交出去的那份对象上
只有读裸，进程不会崩。要有一个并发的写，落在同一张 map 上。
管理器自己的刷新不是这种写。
refreshAuthForRequestAtEpoch 先把当前凭证 Clone() 一份，刷完再作为新对象发布回去；PrepareRequestAuth 同样是先 Clone() 再改，改完才回到管理器。7就地写发生在交给执行器的那份对象上。antigravity 的刷新拿到新 token 后，直接往
auth.Metadata 里连写六个键，中间没有别的保护。8
internal/runtime/executor/antigravity_executor_auth.go 第 127–146 行：第 134 行判断 map 是否为空，第 137 行写 access_token，第 139、141、143、144、145 行接着写 refresh_token、expires_in、timestamp、expired 与 type，没有一把按凭证的锁包住这六行。(antigravity_executor_auth.go) 于是分界线只剩一句话：这份
*Auth 有没有被两个 goroutine 同时拿着。标准代理这条路上没有。每个请求从管理器取一份副本，用完即弃。自己把执行器嵌进服务、或者写插件把同一份 credential 交到多个协程里的，就有。
作者在 PR 正文里也是这么自限的：常规代理里没找到崩溃，只有共享同一个
*Auth 才够得着。1 报障人的原话是高并发下「可以经验性复现」。两句并不互相矛盾，但也谁也证明不了谁。能确定的是修法方向：把锁下沉到
authMetadataString 与 Clone 本身，而不是再补一个 provider。三、两张补丁锁住的，只是 Claude 那几处
把两份改动清单摆在一起，边界很清楚：
internal/auth/claude、claude_executor_*、helps/claude_credential_identity.go。classification.go、types.go 的 Clone、conductor_refresh.go 那三个读函数，一个没动。报障人点名要泛化的，正是这三处。还有一件。这两张单在 04:37 与 05:02 各跑过一次自动评审，结论都是没有发现。10 机器评审没看出问题，生产栈是从人这一侧进来的。
两单现在都 open、mergeable clean、各一笔提交。
四、sub2api：#8305 已经进了 main，但没发版
三处改动，你都能对上自己那一版。
默认出站身份换成
codex_cli_rs。 v0.2.17 里 CodexDefaultOriginator 还是 codex-tui；main 上这个常量等于 CodexCLIOriginator，旧 TUI 配置会被同时改写 originator 与 UA 首段。13
c5b8112 的 backend/internal/service/openai_gateway_upstream_errors.go 第 196–232 行：第 198 行定 openAIRequestScopedRetryMaxDelay = 8 * time.Second，第 206–211 行依次读六个来源，第 227–228 行超过上限就压回 8 秒。(openai_gateway_upstream_errors.go) 这条只挂在容量让渡上。原来的 429 那条路本来就有自己的 8 秒上限，容量让渡之前是本地从 500 毫秒起翻倍，完全不看上游说了等多久。
发版这一层要说准：v0.2.17 是 10 月 16 日发的，今天还是它。这三处只在 main 上，你现在拉 v0.2.17 吃不到。
作者自己在正文里划了两次边界：2003 条上游错误里 1750 条是 overload，那是错误样本统计，不是错误率；「客户端 5xx 为 0」也不等于排除了 HTTP 200 的流内报错。
五、codex2api：一个合法的 input item 被本地拦了
Codex 在 GPT-6 系列的多轮请求里会塞一条
configuration_update，用来改变后续轮次的推理强度。本地校验的白名单里没有这个类型，请求在转发前就被拒成 400。
api/validation.go 第 699–731 行：白名单最后一条是第 718 行的 image，第 719 行合上 map；第 734 行的判定只要 itemType 非空且不在表里，就返回 invalid_input_type。(validation.go) 这类 item 不是编出来的。CLIProxyAPI 专门有一个折叠实现：把这种 item 删掉，再把最后一条非空
reasoning.effort 提到顶层。18同一个请求打到 CLIProxyAPI 会被折叠后放行，打到 codex2api 会 400。要不要现在动，取决于你上游吃不吃这条 item：先在一台测试实例上把它加进白名单试一次，比直接改线上稳。
六、上游与额度
OpenAI 11:41 开的那条支持响应延迟，13:58 已恢复，影响级别写的是 none。19 它落在支持系统上，API 面全绿。
Anthropic 全绿、当日没有事件；Google Cloud 最近一条仍停在 10 月 22 日的 europe-west2 多产品事件。20
额度两站还是各记各的。codex-reset 记最近一次已验证全局重置为 10 月 22 日 17:10 UTC、累计 57 次；opentherank 记 17:00 UTC、65 次。2122 同一次重置，差 10 分钟、差 8 次。
codex-reset 那条「明天上午 10 点前」的预告还在信号位，页面标的窗口是北京时间 10 月 24 日凌晨 1 点前、概率 93%。21 两站都还没把它记成已验证重置。
七、今天的处置表
| 处境 | 今天做什么 | 依据 |
|---|---|---|
| 跑标准代理、没写插件 | 风险只在「同一份凭证被多协程共享」；不必今夜升级，但把实例版本与崩溃日志对齐 | conductor_execution.go |
| 自己把执行器嵌进服务 | 交给执行器前自己 Clone() 一份，别把同一个 *Auth 分给多个协程 | antigravity_executor_auth.go |
| 写插件、多路复用同一凭证 | 同上；这条是栈上那条读唯一能被打断的地方 | classification.go |
| 等修复 | 盯 #6907 与 #6909，看维护者是否把锁下沉到 authMetadataString 与 Clone | PR #6909 |
| 等 sub2api 缓解 overload | 等下一版；v0.2.17 没有这三处改动 | PR #8305 |
用 codex2api 且客户端会发 configuration_update | 先在测试实例上把该类型加进白名单，再上线上 | validation.go |
References
- 1PR #6907 下的生产崩溃报告
github.com
- 2classification.go 第 141–152 行
github.com
- 3conductor_refresh.go 第 401–412 行
github.com
- 4types.go 第 1164–1174 行
github.com
- 5selector.go 第 823–840 行
github.com
- 6v8.0.38 的同一个函数
github.com
- 7conductor_execution.go 第 1554–1572 行
github.com
- 8antigravity_executor_auth.go 第 128–146 行
github.com
- 9PR #6909
github.com
- 10#6907 的评审回执
github.com
- 11sub2api PR #8305
github.com
- 12#8239 的现状
github.com
- 13v0.2.17 的默认身份
github.com
- 14main 上的新函数
github.com
- 15main 上的判定
github.com
- 16codex2api #821
github.com
- 17validation.go 第 674–719 行
github.com
- 18configuration_update.go 第 48–72 行
github.com
- 19OpenAI 状态页事件
status.openai.com
- 20Google Cloud 事件清单
status.cloud.google.com
- 21codex-reset
codex-reset.com
- 22opentherank
opentherank.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.