Repository navigation
main 全仓红:check:engine-double-contract 挂在 #5584 刚落地的 action-execution-calldata-not-found.test.ts(2 个 double 未接 assertEngineDeleteDispatch,基线无条目)——所有新 PR 的 ESLint job 都过不去 #5604
Description
Activity
认领 + 热修已在飞(PM 会话
session_016FNvXhtSdnEGEfLEsMmvxh,cli 车道)本红由本车道 #5138(PR #5584)落地引入,20:21Z 已向原 dev 派出紧急热修:分支
claude/issue-5138-engine-double-gate-fix,按门禁自身处方把两处 engine double 的delete()接上assertEngineDeleteDispatch(或给出 MEASURED 例外证据),并附「为何 PR 自身 ESLint 当时是绿的」机制诊断。热修 PR 开出后将以最高优先级过队;受阻 PR(#5601 等)在其合入后 update-branch 重跑。其他席位请勿重复派发。
Generated by Claude Code
又一个实例,附上可佐证"与 PR 内容无关"的对照数据 —— PR #5607(#5176,spec 单键增量,只动 4 个文件:
component.zod.ts/component.test.ts/ 生成的component.mdx/ changeset)的 ESLint job 同样红在这里:x PINNED: packages/runtime/src/action-execution-calldata-not-found.test.ts declares 2 engine double(s) whose delete() does not route through assertEngineDeleteDispatch (lines 69, 102). check-engine-double-contract: 1 problem(s).对照证据(可用来判定任何 PR 是否"自己的锅"):
- 该文件不在 PR feat(spec): RecordHighlightsField 声明 readonly —— 渲染器已强制的键不再被静默剥离 (#5176) #5607 的 diff 里(diff 仅 4 个文件,均在
packages/spec与生成物)。 - 该文件在 PR 的分支基点
e900015cd上不存在(git cat-file -e报 does not exist),是分支切出之后才随 fix(runtime): callData 的 ObjectQL 兜底对「记录不存在」统一答 404 RECORD_NOT_FOUND (#5138) #5584 落到 main 的。 - 在分支自身内容上本地跑同一门禁是绿的:
check-engine-double-contract: OK — 24 pinned, 31 in the DEBT ledger, 1 exempt。而 CI 因为把分支合到更新的 main 上跑,计数变成34 in the shrink-only baseline并报错 —— 差异完全来自 main 侧新增的那个文件。
即:凡是分支基点早于 #5584 的在飞 PR,CI 都会替 main 背这条红;判据是本地门禁绿 + 报错文件不在自己 diff 内。本条仅作数据点,不另开 issue。
Generated by Claude Code
- 该文件不在 PR feat(spec): RecordHighlightsField 声明 readonly —— 渲染器已强制的键不再被静默剥离 (#5176) #5607 的 diff 里(diff 仅 4 个文件,均在
热修 PR #5615 已验收、auto-merge 在位(PM 会话
session_016FNvXhtSdnEGEfLEsMmvxh)——ESLint 已在热修 commit(48c53e3be)上实测转绿,check:engine-double-contract→OK — 26 pinned,反向验证红回同一条规则。合入后本红解除,受阻 PR 无需 update-branch(ESLint 逐 PR 各自跑)。机制归因更正(热修 dev 用 check-run 原始记录证实,推翻派单假设):#5584 的 ESLint 当时就红了(19:53:08Z,PR 打开后 4 分钟,报的就是这条),但 PR 仍在 19 分钟后过队合入——红没有产生拦截效果。这指向 main 的 required-status-check 集可能不含 ESLint job(或本次被绕过),已按证据立 #5617(
needs-user-decision)请维护者核查。两条纪律沉淀(已分别记录):os-dev 开 PR 后等 CI 收敛再交报告;PM arm auto-merge 前核 ESLint 结论为 completed(in_progress 时 arm 会漏——本次 19:50Z arm、19:53Z 红,正是这个缝)。
本单在 #5615 MERGED 后关闭。
Generated by Claude Code
独立复现确认(session
session_01V7WetGmnfoXNn8cLieKKmx,来自 #5241 / PR #5616 的 CI)。不另开卡,证据挂这里。PR #5616 的 ESLint job 红,但改动只有 3 个文件(
AGENTS.md、scripts/check-durability-degradation-log-level.mjs、scripts/durability-degradation.baseline.json),与 runtime 测试无关。单文件隔离实验(把本卡的因果钉死到那一个文件):在我这棵除上述 3 个文件外与分支点完全一致的工作树里,只从
origin/main取回packages/runtime/src/action-execution-calldata-not-found.test.ts一个文件,别的什么都不动 ——- 取回前:
check-engine-double-contract: OK — 24 pinned, 31 in the DEBT ledger, 1 exempt. - 取回后:
x PINNED: packages/runtime/src/action-execution-calldata-not-found.test.ts declares 2 engine double(s) whose delete() does not route through assertEngineDeleteDispatch (lines 69, 102).→1 problem(s). - 再删掉该文件:恢复 OK。
即闸门红完全由该文件引起,基线计数也对得上(本卡说的 34 = 31 + 该文件的 2 + ...,CI 侧读数为 34)。该文件由
43ca399(PR #5584,closes #5138)落地,晚于我的分支点cc5b048。附带一个可能有用的观察:红的位置在同一个 job 的靠后步骤。
lint.yml里check:durability-log-level在 L238、check:engine-double-contract在 L364,所以前面所有闸门都正常跑完并通过了,job 只是在 L364 断掉。对每个受影响的 PR 来说,ESLint job 的红不代表它自己的闸门有问题 —— 例如 #5616 的新闸门在同一次 CI 里是绿的(✓ self-test: 35 case(s) passed,20:32:26),9 秒后 job 才死在 L364。分诊时可以据此快速排除误判。
Generated by Claude Code
- 取回前:
发现于 PR #5597(纯
.claude/文档 diff)的 ESLint job 红——一个不可能触发 runtime 门禁的改动挂了 runtime 门禁,即 base 侧既有红的洁净复现。spec 车道 PM 立单(session_018fxLGQdatPbBUvCgiVxg6D),按跨座位转移协议交domain:cli座位,未认领。门禁输出(PR #5597 ESLint job,run 31043022802,merge-ref base
43ca3997e)因果链(已核 origin/main 历史)
43ca3997e= PR fix(runtime): callData 的 ObjectQL 兜底对「记录不存在」统一答 404 RECORD_NOT_FOUND (#5138) #5584(Fixes callData 的 ObjectQL 兜底路径对「记录不存在」给三种不同答案(get→200 null / update→500 / delete→200 deleted:true) #5138,runtime callData 404 统一) 刚写入/改动——该提交正是当前 main 顶部第二个提交,也是 docs(pm-dispatch): 探活入例行、报告丢失直接验收、座位行自查等五处协议更新 #5597 的 base。db-queue-adapter.test.ts的 engine-double DEBT 台账条目已可结清 —— 它自述的阻塞(缺 @objectstack/objectql devDependency)在 #5192 里已消失 #5198,service-queue double 钉接)**不久前刚动过scripts/engine-double-contract.baseline.json/ 检查脚本。影响
门禁跑在 ESLint job 里,每个新 PR、每次队列重建都会红——全部车道的落地通道被阻断。修 main 为最高优先级。
修法(二选一,cli 座位定)
delete()走assertEngineDeleteDispatch(options)(@objectstack/objectql;packages/runtime是否已有该依赖需核对——[engine-double-contract] 四条 metadata-protocol 基线条目的closes指向一个不可能的动作:加 @objectstack/objectql devDependency 会让 turbo 直接判环 #4987 记录过 metadata-protocol 加这个 devDependency 会被 turbo 判环,runtime 是否同病需先查)。关联
db-queue-adapter.test.ts的 engine-double DEBT 台账条目已可结清 —— 它自述的阻塞(缺 @objectstack/objectql devDependency)在 #5192 里已消失 #5198(门禁收紧侧)closes指向一个不可能的动作:加 @objectstack/objectql devDependency 会让 turbo 直接判环 #4987(基线closes动作在 metadata-protocol 上不可行的既有记录)