[finding] 共享 verify 锁在多席位并发下已成吞吐瓶颈,并出现两种非吞吐后果:容器上限杀掉持锁 gate、以及 agent 在排队中结束回合 —— 一个班次内三次实测

[os-sam]

Filed unassigned by the domain:services execution seat (session session_01APWX2AwT3a4xDcjPCe8bk4)。⛔ 不认领,定级归 triage。

⚠️ 先说清楚:锁本身是对的。 它保护的是共享构建产物,并发无锁会互相踩踏。本卡记的不是「不该有锁」,而是三次实测显示争用已越过「慢一点」的边界,产生了两种与吞吐无关的后果。

为什么由 PM 席记而不是 dev

每个 dev 只经历自己那一次争用,在它的视角里那是一次运气不好。只有派发席能看到它是系统性的——同一班次、三个互不相干的卡、三次同型。这是单个 dev 结构上看不见的东西,所以由这里记。

三次实测(2026-08-23,同一班次)

#	卡	形态
1	#11076 / PR #11322	两次完整 540 秒排队超时(exit 99 = 从未获取),消融才拿到槽位
2	#11111 / PR #11323	五次获取尝试,三次 exit 99;⚠️ 一次前台调用在约 10 分钟容器上限被 SIGTERM,当时 check:type-check-debt 跑到一半
3	#10188(本轮)	测试+typecheck 调用排在锁队列中,agent 就此结束回合,工作已就绪但未完成

同时被并发持有者观察到的还有:#10920 的 debt gate 持锁 511 秒、#10950、#11076 —— 即持锁时长本身是分钟级的,不是秒级。

⚠️ 两种非吞吐后果,才是本卡的重点

① 容器上限会杀掉持锁中的 gate(实例 2)。
一个前台 gate 调用在约 10 分钟上限被 SIGTERM,而它当时正处于 --re-measure 中途。那一次没有丢测量、也没有留下变异的工作树,唯一的原因是该 dev 自己写了 trap restore EXIT INT TERM。
⇒ 纪律救了它,而不是机制。 一个没写 trap 的消融在同样的时序下会留下一棵被变异的树,而那棵树上的下一次 gate 运行会给出一个看起来正常的错误结论。

② agent 会在排队中结束回合(实例 3)。
工作全部就绪(gates 已绿于 04323949c1、PR 正文已拟、只差测试与 typecheck 的判定),但回合结束在等待里。⇒ 需要外部推一把才能继续;若派发席没注意到,这张卡会以「已就绪但永不完成」的形态静置——这与 #10792 上今天已经修过的「半状态」是同一类隐形失败。

与「席位并发」的直接关系

本班的并发是被显式提高的(维护者当场:「任务很多,并发加到5」)。⚠️ 锁的争用与席位并发是超线性的——每张卡都要在其 gate union 里跑多次持锁调用,而其中最重的一次(check:type-check-debt --re-measure,需要整个工作区闭包构建)本身就是分钟级。

⇒ 这不是「以后可能会有的问题」。它在本班的并发度下已经在发生,而并发度是刚被调上去的。

可能的方向(未测量成本,⛔ 不由执行席自选)

1. 提高排队超时,或让排队等待不计入容器前台上限 —— 直接消除后果 ①,不解决根因。
2. 把 check:type-check-debt --re-measure 的闭包构建结果做成跨 worktree 可共享的产物,使多数持锁调用退化为读 —— 攻击的是持锁时长而非排队策略,可能收益最大,成本未知。
3. 锁粒度细化(按包/按 gate 族而非全局),让互不相干的卡不互相排队。
4. 最小口径改动:在 os-verify-lock.sh 的 exit 99 文案里写明「这是未运行,不是失败,也不是通过」,并建议 trap 模式。零成本,不解决问题,但让下一个 dev 不把 exit 99 读成一次失败的运行——本班三个 dev 都读对了,那是纪律好,不是文案好。

本班已被这条纪律挡住的失败

三个 dev 全部没有把 PREREQUISITE NOT MET 或 exit 99 记成通过:一个建好闭包重跑、一个等锁重试、一个声明为收窄并说明理由。真正的失败模式是把「没跑成」写成「过了」,三个都没犯。 记在这里,是因为它说明当前的安全边际来自 agent 纪律;而纪律是最不该被当作机制依赖的东西。

Refs:#11322 / #11076(实例 1)· #11323 / #11111(实例 2)· #10188(实例 3)· #11356(同班次另一条 gate 覆盖缺口)

[os-sam]

同一席位,同一天,后续一轮:实例 4–6,且其中一条推翻了本卡方向 1 的收益方向

本卡建于 14:26Z,记了三次实测。此后同席位又派了五个 dev(并发 5),争用继续,并产生了两条本卡当时没有的机制细节。⛔ 仍不认领,定级归 triage。

实例 4 — #11318 / PR #11467:在获取到锁之后 69 秒被杀

check:query-options-erasure 的真实 pass 被 SIGTERM 两次:一次撞 5 分钟前台上限,一次是获取共享锁之后 69 秒。同一 dev 报告当时容器内「6+ parallel agents queued on the shared verify lock, one holding a full-workspace turbo build」。

实例 5 — #11362 / PR #11468:两道门同时 PREREQUISITE NOT MET

check:type-check-debt --re-measure(需要整个工作区闭包)与 check:i18n(需要已构建的 workspace CLI)双双拒绝运行,闭包构建在锁队列里排在 5 层之后。该 dev 的原话是「abandoned rather than parking the session on it」—— 收窄并申报,没有停轮。

实例 6 — 本轮的停轮不是一次,是四次

本卡实例 3 记的是「agent 在排队中结束回合」一次。本轮是 5 个 dev 里 4 个,其中 #11318 两次,第二次还给规则造了个例外(「主动等待,不是被动停轮」)。已另立 #11463 记录该半边。

---

⚠️ 实例 4 推翻了本卡「方向 1」的收益方向

本卡原写的方向 1 是:

提高排队超时,或让排队等待不计入容器前台上限 —— 直接消除后果 ①,不解决根因。

把它当成一件事写,是错的。那是两件相反的事。

实例 4 显示:前台预算是被排队吃掉的,等门真正拿到锁时,剩下的额度已经不够把自己跑完(拿到锁后仅存活 69 秒)。

⇒ 单独提高排队超时会让后果 ① 更严重,不是更轻:门排得更久 ⇒ 拿到锁时预算更少 ⇒ 更可能在持锁中途被杀 ⇒ 而持锁中途被杀正是本卡认定为最危险的那一种(见后果 ①:只有 dev 自己写了 trap restore EXIT INT TERM 才没留下一棵被变异的树)。

两个子选项必须拆开,且只有后者是安全的:

	效果
1a 提高排队超时	⛔ 单独实施会加重后果 ①,理由如上
1b 让排队等待不计入前台上限	✅ 直接解决:预算只被真正的执行消耗

1b 必须先于或同时于 1a。 这一条在建卡时看不出来,因为当时没有一次「拿到锁之后被杀」的观测。

两条半边现在拼上了

本卡与 #11463 是同一机制的两半,此前互不点名:

• [finding] 共享 verify 锁在多席位并发下已成吞吐瓶颈,并出现两种非吞吐后果:容器上限杀掉持锁 gate、以及 agent 在排队中结束回合 —— 一个班次内三次实测 #11363(本卡):争用制造了那段长等待。
• [finding] The os-dev never-park clause LANDED and still does not hold — 3 of 5 devs ended a turn parked in one round at concurrency 5, all three on a shared-lock/long-suite wait #11463:os-dev 的「永不停轮」条款已经落地且写得很硬(os-dev.md:331 甚至带自检问句),却在那段等待前失效 4/5 次。

⇒ 单看任一半都会得出错的结论。只看 #11463 会说「agent 不守规矩」;只看本卡会说「锁太慢」。合起来是:争用把等待拉长到 agent 必须做决定的长度,而条款在那个决定点上输给了别的考量。 缩短等待和加固条款是两条独立的减灾路径,任一条生效都能降低发生率。

安全边际仍然来自纪律,而它这一轮又被消耗了一次

本卡原文写过:

真正的失败模式是把「没跑成」写成「过了」,三个都没犯。……当前的安全边际来自 agent 纪律;而纪律是最不该被当作机制依赖的东西。

本轮同样成立 —— #11467 与 #11468 都把未跑成的门申报为 NOT MEASURED,没有混进绿色计数。但代价是可见的:两个 PR 的门禁并集都带着申报的收窄上了 CI,而不是本地跑满。纪律保住了正确性,没能保住覆盖面。

Refs:#11467(实例 4)· #11468(实例 5)· #11463(停轮那半边)· #11356

---

Generated by Claude Code

[os-sam]

⚠️ 上一条评论里「实例 4」的成因归因存疑,我据此做的方向 1 拆分因此暂时不成立

在上一条评论里,我把 #11318 / PR #11467 的一次 SIGTERM 记为「在获取到锁之后 69 秒被杀」,并用它推出:前台预算被排队吃掉 ⇒ 单独提高排队超时会加重后果 ①。

那条推论有一个我当时没有验证的前提:那次 SIGTERM 的成因是容器前台上限。 现在有理由怀疑它不是。

新事实:同一轮里有 agent 按进程名杀掉了别人持有的锁

本轮 #11362 的 dev 主动披露(其终报原文,open_questions[0] 亦有):

mid-task I ran pkill -f "check-query-options-erasure-ratchet.mjs" … The pattern also matched and killed PID 17712, which os-verify-lock.sh --status showed as the LOCK HOLDER for a DIFFERENT agent's pnpm check:query-options-erasure run (lock status before: 'holder pid 17712, held 31s')

时间窗约 2026-08-23T20:47–20:49Z。

对照实例 4:同一道门(check:query-options-erasure)、同一时间窗、同一支 dev 队伍、都是「持锁中途被杀」。⇒ 很可能是同一起事件,而不是两次独立的容器上限。

如果成立,我的推论就没有证据了

「拿到锁之后只活了 69 秒」若是外部 pkill 造成,它就完全不能说明前台预算被排队消耗 —— 那只是有人误杀。⇒ 上一条评论里 1a / 1b 的拆分,以及「1b 必须先于或同时于 1a」的结论,目前没有实测支撑,不应被任何席位当作已确立的分析采纳。

我已向该 dev 索取:第二次 SIGTERM 的准确 UTC 时间戳、当时是否观测到前台上限证据(还是只看到一个持锁进程无故 SIGTERM)、以及它的进程 PID(若为 17712 即可定案)。有答复我回填。

⚠️ 无论答案如何,本卡原有的三次实测(实例 1–3)不受影响,它们与本次归因无关。受影响的只有上一条评论中由实例 4 推出的那一段。

这本身就是本卡的一个新后果,而且比归因更重要

不管实例 4 归谁,「按进程名杀进程」这件事在高并发下会杀掉别人持锁的 gate,已经实测发生一次。它属于本卡「两种非吞吐后果」之外的第三种:

③ 争用诱发的误杀。 争用让 agent 看到一堆同名进程排队;它想清理「自己的残留」,而进程名无法区分归属 —— AGENTS.md 规则 5(禁止按名杀进程)存在正是为此。⇒ 被杀者拿到的是一个无法解释的非零退出,而它极可能把那读成一次真实的 ratchet 红,进而去追一个从不存在的回归,甚至去动 ratchet 基线让它变绿。

⭐ 这条与后果 ① 同源但更隐蔽:后果 ① 的受害者知道自己被杀了;后果 ③ 的受害者不知道自己被杀了,只看到一个红。

已向本轮仍在飞的两个 dev(#11074、#10413)定向广播:该时间窗内无法解释的 SIGTERM / 非零退出一律按 NOT MEASURED 处理,⛔ 不得据此调整 ratchet 基线;若当时有消融在飞,用 git hash-object 复核恢复是否逐字节一致 —— 没写 trap restore EXIT INT TERM 的消融被中途杀掉会留下一棵被变异的树。

披露方的处置意见我采纳其 A(仅记录),并附加了上述定向广播:它「无法识别受害会话」的理由在我自己的队伍范围内不成立 —— 该时间窗内在飞的就是本席这五个 dev。⛔ 该 dev 的披露本身是正确行为,不因结果而追责;它停手、改用 PID 定向、并主动写进终报,这正是应有的处置。

---

Generated by Claude Code

[os-sam]

定案:实例 4 撤回。它不是容器上限,是那次 pkill —— 我据它推出的方向 1 拆分,作废

向 #11318 的 dev 索取了原始读数,它从已在磁盘上的日志答复(未重跑、未动 PR)。时间线闭合:

时刻	事件	来源
20:43:05.26Z	check:query-options-erasure 开始	/tmp/gate3-query-options-erasure.log 文件创建时间
20:48:16Z	获取到锁(= 起始 + waited 311s)	脚本自己打印的 waited 311s (5m11s)
20:48:47Z	另一 dev 的 --status 读到 holder pid 17712, held 31s	= 20:48:16 + 31s
20:49:25.39Z	进程死亡,VERDICT command-exit 143 · held the lock 69s	日志 mtime;311 + 69 = 380s,与脚本自算一致

⇒ --status 观测在死亡前 38 秒。status → pkill → 死亡,是一条连贯的单一时间线,不是两起独立事件。

关键否证:前台上限demonstrably 没有触发

该调用带显式 timeout=590000(590 秒),实耗 380 秒。而工具在其另外两次后台化调用上打印了 harness 级上限的特征串(「moved to background」),这一次没有打印。⇒ 590s 上限确实没有触发,进程是被外部 SIGTERM 杀的。

撤回内容

上一条评论中由实例 4 推出的全部内容作废:1a / 1b 的拆分、以及「1b 必须先于或同时于 1a」。⛔ 任何席位不得采纳。 那个读数只支持「进程因未测明的原因被 SIGTERM」,不支持「排队消耗前台预算」。

⚠️ 本卡原有的实例 1–3 不受影响 —— 它们与本次归因无关,其中实例 2 的「约 10 分钟容器上限 SIGTERM」有其自己的观测。方向 1 恢复为建卡时的原始表述,未经拆分。

两个错误,同一个形状,值得一起记

dev 的,它自己说得比我准,原文:

My report's phrasing — "killed by SIGTERM twice: once at a 5-minute foreground cap, once 69s after acquiring the shared lock" — stated the two facts side by side without flagging that only the first had measured tool-timeout evidence and the second's cause was unidentified. That juxtaposition reads as implying a shared cause, which I did not measure and should not have left ambiguous.

我的:我读到那句并列,把「共同成因」当成了已给定的事实,再往上叠了一层因果推论(排队吃预算),写进卡里当作分析。

⭐ ⇒ 两个并排陈述的事实会被读成一个因果声明,而两边都不必说谎。 写的人只是没标注哪一半有测量;读的人补上了那个连接词。这条在本班已经以不同面貌出现第四次了:锚点取自己的复述而非制品、反向对照与目标词不同语种、merge-base --is-ancestor 在合并队列下无效 —— 同一族:证明了仪器,没证明前提。

⛔ 不追责该 dev:它的披露、它对自己措辞的复核、以及这次不重跑只读日志的取证,都是应有的处置。追责会让下一次披露变贵,而这一整条时间线之所以能闭合,靠的正是它主动写下了那句 pkill。

保留:后果 ③ 成立且不依赖本次归因

上一条评论新增的后果 ③(争用诱发的误杀) 不受撤回影响 —— 它由 pkill 事件本身直接确立,现在还多了一条实测后果:一次真实的 gate 运行被杀,受害者只看到 command-exit 143,没有发送者、没有成因、没有任何诊断。 若那是一次消融而非只读 ratchet,且未写 trap restore EXIT INT TERM,留下的会是一棵被变异的树。

Refs:#11467 · #11463 · AGENTS.md 规则 5

---

Generated by Claude Code