Skip to content

test(spec): 给 13 个 compiler-API 导出面 pin 一个符合真实工作量的超时 —— 今晨全部 CI 红的真因 (#4796) - #4864

Closed
os-zhuang wants to merge 1 commit into
mainfrom
claude/issue-4796-compiler-pin-timeout
Closed

test(spec): 给 13 个 compiler-API 导出面 pin 一个符合真实工作量的超时 —— 今晨全部 CI 红的真因 (#4796)#4864
os-zhuang wants to merge 1 commit into
mainfrom
claude/issue-4796-compiler-pin-timeout

Conversation

@os-zhuang

Copy link
Copy Markdown
Contributor

Fixes #4796
Refs #4845

真因(来自完整日志归档,不是尾部截断)

下载 run 30804783487 的完整日志后,失败明细第一次完整可见:

FAIL src/automation/state-machine.test.ts  [#4658] EventSchema pin        × 5602ms
FAIL src/automation/sync-retirement.test.ts [#4738] sync/conflict pin     × 5379ms
FAIL src/cloud/tenant.test.ts               [#4739] TenantPlan pin        × 5022ms
Error: Test timed out in 5000ms.  (×3)
Tests  3 failed | 7359 passed (7362)

全是超时,不是 OOM,与各 PR 的改动内容无关。 #4796 立案时只记了 tenant.test.ts 一条;实测这是一族 —— packages/spec13 个 compiler-API 导出面 pin(每个退役/双源 PR 各留一个),零个有显式超时,全部骑在 vitest 默认 5s 线上。

为什么 CI 中而本地不中(按 #4796 的要求「先测量再决定」)

这族 pin 每个都对全部 16 个公共入口建一次 ts.createProgram —— 天然秒级:

环境 实测耗时
空闲机器(13 GB 可用) ~2-3s
CI 分片(turbo 把 spec#buildspec#test 并发跑在同 4 vCPU 上) 5.0 / 5.4 / 5.6s

争抢是概率性的 —— 这解释了「与改动内容无关、重跑可过、专挑真跑 spec 的 PR」的全部观测。今晨四次命中(#4831 ×2 含合并队列、#4841#4846)加上 #4796 立案时的两次,共六次把 PR 或队列打红。

也顺带解释了 #4845 的误诊:DTS Build start 紧接 ELIFECYCLE并发任务的交织输出(turbo 多任务 stdout + GitHub 按 group 同戳 flush),真正失败的一直是 spec#test,而失败明细在 job log API 只回的 ~10KB 尾部之外。#4845 已更正。

修法与理由

packages/spec/vitest.config.tstestTimeout: 30_000 + 长注释(测量数据、争抢机理、为什么 30s、真挂死由谁兜底):

验证

原三条失败 pin + 今晨新增的 activation-events pin 在新配置下实跑:

Test Files  4 passed (4)
     Tests  17 passed (17)
Duration  7.27s

空 frontmatter changeset(发布面零变化)。content/docs/releases/ 未触碰。

🤖 Generated with Claude Code

https://claude.ai/code/session_0176qgxgCXTJCUv4YFLtusP9


Generated by Claude Code

这一族 pin 都要对全部 16 个公共入口建一次 ts.createProgram,天然秒级。
实测:空闲机器 ~2-3s;CI 分片上 turbo 把 spec#build 与 #test 并发跑在
同 4 vCPU 上,争抢推到 5.0-5.6s —— 恰好骑在 vitest 默认 5s 线上。
一个上午三条 pin 超时(state-machine / sync-retirement / tenant),
每次都把不相干的 PR 踢出合并队列,并曾被误诊为构建 OOM(#4845)。

30s 约为实测争抢峰值 5 倍;真挂死仍由 10 分钟 stall guard 兜底。
长期修法(导出面做成构建期产物、pin 只比对)在 #4796 跟踪。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0176qgxgCXTJCUv4YFLtusP9
@vercel

vercel Bot commented Aug 3, 2026

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment
Project Deployment Actions Updated (UTC)
objectstack Ignored Ignored Aug 3, 2026 10:43am

Request Review

Copy link
Copy Markdown
Contributor Author

关闭:已被 #4856(#4850)superseded —— 另一车道在本 PR 开出前已把同一修复落进 main(d40f43a79,testTimeout: 60_000,注释同样覆盖全族 compiler-API 用例并关联 #4796)。

本 PR 若合入反而会把 60s 降回 30s 并覆盖对方的注释 —— 纯粹的车道重复,撤下。测量数据(空闲 ~2-3s / CI 争抢 5.0-5.6s、争抢源 = turbo 把 spec#build#test 并发在同 4 vCPU)已记录在 #4796 评论中,对两个版本的修复同样成立;60s 余量更大,无异议。


Generated by Claude Code

@os-zhuang os-zhuang closed this Aug 3, 2026
auto-merge was automatically disabled August 3, 2026 10:45

Pull request was closed

akarma-synetal pushed a commit to akarma-synetal/framework that referenced this pull request Aug 4, 2026
…) (objectstack-ai#4893)

2026-08-03 的 v17 协议变更派发里,有四类已经付出过代价的经验,现行 skill 里
没有或只写了半截。同日另一车道的 objectstack-ai#4885 已沉淀八条,本单只补它覆盖边界之外的。

pm-dispatch —— Operational notes 由四条扩到八条:

- 5:rerun_failed_jobs 复用原 run 的提交/合并 ref,不重算。红的原因若是「基上
  缺一个已合并的修复」,重跑无效,只有推新提交才拿得到新的合并 ref(objectstack-ai#4852 因此
  在队列外空转 100 分钟)。与 rerun-safety-nightly.yml 无关,后者查的是测试污染。
- 6:读数纪律。cd X && cmd 短路会在错的仓里执行(跨仓一律 git -C);
  git grep -c | wc -l 数的是文件数不是命中数;裸名 grep 会被幸存家族当子串命中,
  退役核验要带引号精确名、更硬的判据是查声明式而非提及。零命中必须用确定存在的
  邻近词反查。
- 7:CI 红了先取完整日志归档。completeness check 绿只说明没有 worker 静默死掉;
  turbo 并发输出相邻不等于因果(test 的 dependsOn 只有 ^build,spec 无 pretest);
  不要只看 tail。据错误结论开的 PR 要撤回 draft 并解绑 Fixes。
- 8:共享基础设施类修复按症状复查 main。duplicate-fix-guard.yml 只覆盖「同仓 +
  同一个 Fixes #N」,objectstack-ai#4864objectstack-ai#4856 挂在不同 issue 号下,门禁看不到,而后者先合的
  60s 会被前者降回 30s。

另在 note 1 上补:「不在 main 上」是二义读数(兼容「排队中」与「没入队」);队列
分支 base sha 串成链,可读出排第几;转 draft 会同时掉 auto-merge 与队列成员资格。

step 7 之后新增「入队与落地」小节:merge=os-regen 的七条路径(含两条文档产物)、
四步同步协议、以及跟到 MERGED 而不是跟到入队为止。

spec-property-retirement:

- 新增「四张 ratchet 的可见性按路线相反」—— 枚举值收窄不可见(objectstack-ai#4391),整 def
  删除必须变化(objectstack-ai#4834:-12/-23/-5);拿错对照会双向判错。
- 修好第 2 节指向 plugin-runtime.zod.ts:243-248 的先例引用,该文件已被 objectstack-ai#4878
  整体删除。

Fixes objectstack-ai#4892


Claude-Session: https://claude.ai/code/session_0176qgxgCXTJCUv4YFLtusP9

Co-authored-by: Claude <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

flaky: spec/src/cloud/tenant.test.ts 的 #4739 导出面用例贴着 5s 超时 —— 今晚已两次把不相干的 PR 踢出合并队列

2 participants