test(spec): 给 13 个 compiler-API 导出面 pin 一个符合真实工作量的超时 —— 今晨全部 CI 红的真因 (#4796) - #4864
Closed
os-zhuang wants to merge 1 commit into
Closed
test(spec): 给 13 个 compiler-API 导出面 pin 一个符合真实工作量的超时 —— 今晨全部 CI 红的真因 (#4796)#4864os-zhuang wants to merge 1 commit into
os-zhuang wants to merge 1 commit into
Conversation
这一族 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
|
The latest updates on your projects. Learn more about Vercel for GitHub. 1 Skipped Deployment
|
os-zhuang
marked this pull request as ready for review
August 3, 2026 10:43
os-zhuang
enabled auto-merge
August 3, 2026 10:43
Contributor
Author
|
关闭:已被 #4856(#4850)superseded —— 另一车道在本 PR 开出前已把同一修复落进 main( 本 PR 若合入反而会把 60s 降回 30s 并覆盖对方的注释 —— 纯粹的车道重复,撤下。测量数据(空闲 ~2-3s / CI 争抢 5.0-5.6s、争抢源 = turbo 把 Generated by Claude Code |
auto-merge was automatically disabled
August 3, 2026 10:45
Pull request was closed
This was referenced Aug 3, 2026
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#4864 与 objectstack-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>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #4796
Refs #4845
真因(来自完整日志归档,不是尾部截断)
下载 run
30804783487的完整日志后,失败明细第一次完整可见:全是超时,不是 OOM,与各 PR 的改动内容无关。 #4796 立案时只记了
tenant.test.ts一条;实测这是一族 ——packages/spec里 13 个 compiler-API 导出面 pin(每个退役/双源 PR 各留一个),零个有显式超时,全部骑在 vitest 默认 5s 线上。为什么 CI 中而本地不中(按 #4796 的要求「先测量再决定」)
这族 pin 每个都对全部 16 个公共入口建一次
ts.createProgram—— 天然秒级:spec#build与spec#test并发跑在同 4 vCPU 上)争抢是概率性的 —— 这解释了「与改动内容无关、重跑可过、专挑真跑 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.ts设testTimeout: 30_000+ 长注释(测量数据、争抢机理、为什么 30s、真挂死由谁兜底):run-with-stall-guard.mjs才是挂死检测器)—— 这个数字只阻止「健康但受争抢」的运行被读成失败;spec/src/cloud/tenant.test.ts的 #4739 导出面用例贴着 5s 超时 —— 今晚已两次把不相干的 PR 踢出合并队列 #4796 的方案 2(导出面做成构建期产物、pin 只比对不现场解析)仍是长期正解,本 PR 不关闭那个方向,issue 保持追踪。验证
原三条失败 pin + 今晨新增的 activation-events pin 在新配置下实跑:
空 frontmatter changeset(发布面零变化)。
content/docs/releases/未触碰。🤖 Generated with Claude Code
https://claude.ai/code/session_0176qgxgCXTJCUv4YFLtusP9
Generated by Claude Code