观察类 finding,来自 PR #5398 队列「变黄」的诊断(2026-08-05,只读调查,无任何状态干预)。记录备查,由分诊轮定级。未认领。
实测事实
Turbo 缓存只由 main 分支 run 写入(Save Turbo cache (main only) 在每个 merge_group run 上都是 skipped);merge_group 条目只能读。于是当一个队列条目在前一次 main 合并后立刻入队时:
| 步骤 |
pr-5395 条目(基线) |
pr-5398 条目(受影响) |
| Restore Turbo cache |
5 秒,HIT |
0 秒,MISS |
| Build workspace packages |
4 秒 |
4+ 分钟(整仓冷构建) |
| Lint & Type Check job 总耗时 |
3m36s |
~8-10 分钟 |
机制:给 f417863f 写缓存的 main push run(30985383811)07:31:52 → 07:35:23 才写完,而 pr-5398 的队列条目 07:34:18 就到达恢复步 —— 早了 ~65 秒,整个 workspace 冷建。时序竞态,结构性:任何紧跟 main 合并 ~4 分钟内入队的条目必然命中。
影响
- 不是故障:构建照常成功,只是慢;条目仍在正常 10-20 分钟带内的偏慢端。
- 但它是连续合并的固定税:队列吞吐越高付得越多(今天单日 ~10 次合并的节奏,尾对尾入队几乎必中),且表现为「队列黄得比平时久」,已经消耗过一次人工排查(本单的由来)。
可能方向(未定)
- 让 merge_group run 可读 main 的缓存键(restore keys 加 main 前缀,只读不写,不破坏缓存单写者纪律);
- 或队列条目的构建步对「前一 main run 的 cache-save 尚未完成」做短等待;
- 或接受现状,把本单作为「队列黄 >N 分钟」排查手册里的已知良性原因记录。
方向 1 最小且不改写入方;定级与派发由发现分诊轮裁。
关联:PR #5398(诊断现场)、#4845(另一次「构建慢/黄」误诊的教训:先量再改)、.github/workflows/ci.yml 的 Turbo cache 步骤。
观察类 finding,来自 PR #5398 队列「变黄」的诊断(2026-08-05,只读调查,无任何状态干预)。记录备查,由分诊轮定级。未认领。
实测事实
Turbo 缓存只由 main 分支 run 写入(
Save Turbo cache (main only)在每个 merge_group run 上都是skipped);merge_group 条目只能读。于是当一个队列条目在前一次 main 合并后立刻入队时:机制:给
f417863f写缓存的 main push run(30985383811)07:31:52 → 07:35:23 才写完,而 pr-5398 的队列条目 07:34:18 就到达恢复步 —— 早了 ~65 秒,整个 workspace 冷建。时序竞态,结构性:任何紧跟 main 合并 ~4 分钟内入队的条目必然命中。影响
可能方向(未定)
方向 1 最小且不改写入方;定级与派发由发现分诊轮裁。
关联:PR #5398(诊断现场)、#4845(另一次「构建慢/黄」误诊的教训:先量再改)、
.github/workflows/ci.yml的 Turbo cache 步骤。