sync-lock-reap.spec.ts 在整套 jest 并行跑、机器同时有重负载时间歇失败: 该套件平时约 5 秒,失败时耗到 68 秒。 根因不是逻辑错,是判据两端取的时间**不同源**: · 界 = PROCESS_STARTED_AT,模块加载时刻 T0 · 造行 = `new Date(Date.now() - 1000)`,用例执行时刻 T0+Δ 减 1 秒 要判成僵尸需要 Δ < 1s;负载高时模块加载到用例执行的间隔超过 1 秒, 行反而落到界**之后**、不再算僵尸 → findMany 空 → updateMany 没被调 → `updateMany.mock.calls[0][0]` 直接抛。 修法:把时间界作参数注入 reapStaleRunningLocks(默认仍是 PROCESS_STARTED_AT, **生产行为一字未变** —— onModuleInit 那个调用点不传参),测试用固定基准 构造 before()/after(),全程不碰真实时钟。 顺带补一条边界断言:startedAt >= 界的行(并存 CLI 的真锁)连 updateMany 都不该发 —— 原来只锁了 where 用 lt 不用 gte,没锁住"真的不碰"这个行为。 ⛔ 没有用调大 jest timeout 掩盖:那只是把失败推后。 验证:并行跑 `next build` 制造负载,连跑 3 次整套 857 测试全绿。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
