观察类记录(finding,不入队),来自 #5702 实施期的一次全包跑。
实测
同一个 worktree、同一份改动,pnpm --filter @objectstack/driver-sql test 连跑两次:
第 1 次: FAIL src/sql-driver-overlay-index-drift.test.ts
> overlay index drift on a fresh database (#4884)
> stays silent on the SECOND boot, when the runtime ledger starts empty again
Test Files 1 failed | 69 passed | 4 skipped (74)
第 2 次: Test Files 70 passed | 4 skipped (74) ← 同一份代码,全绿
归因手法按 §9 走过一遍:把改动 git stash -u 掉,在 pristine origin/main 上跑同一个包 —— 69 passed | 4 skipped,全绿。所以既不是本轮改动造成的,也不能靠「再跑一次」当作证伪 —— 它两边都可能绿。
为什么值得记
用例名字里的 "SECOND boot" 与 "runtime ledger starts empty again" 提示它依赖跨 boot 的状态复位;这类用例在并行 worker 下共享同一个库/账本时最容易互串。本仓 CI 的合并队列对偶发红很敏感(#5499 冻结 mongo 二进制下载,起因就是一次偶发红把无关 PR 踢出队列)。
未做定位,只记录读数 —— 复现频率未测,是否与 --maxWorkers=2 相关未测。
观察类记录(
finding,不入队),来自 #5702 实施期的一次全包跑。实测
同一个 worktree、同一份改动,
pnpm --filter @objectstack/driver-sql test连跑两次:归因手法按 §9 走过一遍:把改动
git stash -u掉,在 pristineorigin/main上跑同一个包 ——69 passed | 4 skipped,全绿。所以既不是本轮改动造成的,也不能靠「再跑一次」当作证伪 —— 它两边都可能绿。为什么值得记
用例名字里的 "SECOND boot" 与 "runtime ledger starts empty again" 提示它依赖跨 boot 的状态复位;这类用例在并行 worker 下共享同一个库/账本时最容易互串。本仓 CI 的合并队列对偶发红很敏感(#5499 冻结 mongo 二进制下载,起因就是一次偶发红把无关 PR 踢出队列)。
未做定位,只记录读数 —— 复现频率未测,是否与
--maxWorkers=2相关未测。