Repository navigation
[P2] zcode_pr_review 深审 LLM 300s 超时三发：Mimosa 正常但无 verdict，私有运维仓线闸缺 #54
Description
Activity
根因调研结论（2026-10-03）
三次超时不是 gate 干的——gate 从未失败过；失败线是另一条没有设超时覆盖的
--call调用，叠加「审查子进程实际跑在非预期慢模型上」的放大器。 修复见 PR #56。排除：gate 侧全净
- journal 全窗口（事发前后 72h）没有任何失败/超时/重试行；state.json 里 #216/#219 均为
reviewed+verdict。 - issue 点名的三个 head（ca81eb4 / 6edfdcf / e6f6a95）在 gate 上全部成功：verdict、评论、报告俱全，耗时 9m04s / 11m43s / 6m13s。
- issue 提到的「两次超时后重启」核实为例行 SIGTERM 优雅重启（旧实例日志里完全没有 216/219 的记录，重启与其无关；重启后 3 秒即正常开审下述成功的审查）。
定位：真凶是另一条调用线
在审查子进程的 runtime 日志里找到四个会话，与 gate 的四次审查（含三个事发 head）时间一一对应（同一批 PR head 推送同时触发两条线）：
- cwd 为 mcp-server 的临时审查目录、首条 prompt 即
zcode_pr_review的深审模板——是经zcode-mcp-server --call zcode_pr_review跑的子进程； - 四个会话全部异常终止：最后一个事件均为
model.request.started后戛然而止（无优雅收尾），寿命 303/236/194/305s——约 300s 处被杀； - 对照组：同一晚另一批直驱 zcode 会话的只读审查（不经 mcp-server，无 300s 预算）耗时 446s/592s 全部干净完成——证明时长本身可达，只是预算不够。
「exit2/isError」的出处：
--call模式对 isError 结果约定退出码 2。mimosa 扫描有独立预算（deep 默认 900s）先正常完成，故呈现「Mimosa 正常但无 verdict」。双根因
- 预算缺失（本 PR 修）：
_review_timeout()默认 300s，只有 review-gate 显式设了 3600。gate 侧 49 次深审实测：两仓中位 305s / 409s，57% / 71% 超 300s——300s 对 deep 档是必然超时，与仓库无关（「集中在私有运维仓」的观感来自：主仓审查走的是 3600s 预算的 gate 线，事发 head 的 exact-head 复核走的是 300s 预算的手动/agent 线——线不同，不是仓不同）。 - 放大器（[compat] 0.16.9 官方 runtime headless：ZCODE_MODEL 等 env 注入疑似失效，模型选择走配置文件（闸门机升级实证） #55，另行跟进）：
ZCODE_MODEL注入被包装器忽略，子进程按 provider 注册表首位解析默认模型——事发机器上首位是第三方慢模型（单请求实测 87-213s），多轮工具循环下深审 5-10 分钟起步。受影响调用线的宿主侧已缓解（headless 默认模型钉回预期值，复现验证通过）。
对 issue 三个待查方向的回应
- deep 超时预算可调 → 机制本就存在（
ZCODE_BRIDGE_REVIEW_TIMEOUT），问题在默认值对未显式设值的调用方不友好——PR fix: 深审超时治理 — review 单次调用默认 300→1200s + 超时结构化标因 (#54) #56 把默认提到 1200s； - 自动重试 / degraded verdict → 超时结构化标因（
timeout: {"seconds": N}顶层键）已随 fix: 深审超时治理 — review 单次调用默认 300→1200s + 超时结构化标因 (#54) #56 落地，是 degraded verdict 的前置件；自动重试暂不做（对慢模型的超时重试只会双倍等待，先修模型解析）； - 配置/模型路由差异 → 无路由差异；差异在「调用线是否设了超时覆盖」+「子进程实际解析到的模型」。
遗留
- [compat] 0.16.9 官方 runtime headless：ZCODE_MODEL 等 env 注入疑似失效，模型选择走配置文件（闸门机升级实证） #55：env 注入失效的系统性修复（含调用侧模型可观测性——
--json的projection/usage均不含模型 id，需另行设计）。 - gate 侧无需动作（预算充足、模型正确、三 head 已成功）。
（本文已于 2026-10-03 做信息安全脱敏编辑：移除基础设施标识/账号与凭据相关细节，技术事实未变。）
- journal 全窗口（事发前后 72h）没有任何失败/超时/重试行；state.json 里 #216/#219 均为
- changed the title
[-][P2] zcode_pr_review 深审 LLM 300s 超时三发：Mimosa 正常但无 verdict，hosted-ops 线闸缺[/-][+][P2] zcode_pr_review 深审 LLM 300s 超时三发：Mimosa 正常但无 verdict，私有运维仓线闸缺[/+]on Oct 3, 2026
现象
近 24h 内三次 exact-head 深审（zcode_pr_review deep）在 LLM 阶段 300s 超时，
exit2/isError，无 verdict 产出：ca81eb4（第二次连续超时）6edfdcfe6f6a95——Mimosa 0/80 基线过滤正常（diff 级扫描零 findings），随后 LLM 深审 300s timeout对照
同时段主仓（openagentemail）五连 PR（#366/#369/#370/#371/#372）ZCode 闸全部正常出 verdict。超时集中在私有运维仓。另 #216 两次超时后闸门账号曾重启，重启后实审主仓 #366 成功。
影响
私有运维仓侧 exact-head 六闸缺一格，调用方已三次书面例外（明示仅本头、不遗传）。若成常态，私有运维仓线闸证将长期依赖人工例外，削弱闸的意义。
待查方向（建议）
环境
闸门账号 @ 闸门机；ZOB main
db5dd1a（2026-09-24 核实同步）；闸模型 GLM-5.3。（本文已于 2026-10-03 做信息安全脱敏编辑：移除基础设施标识/账号与凭据相关细节，技术事实未变。）