finding(objectql): engine.test.ts 的 formula `now` 确定性断言按「值」比较,只有跨毫秒时才会红 —— 一条按运气报警的 pin

[baozhoutao]

观察类 finding,实现 #5699(PR #5894)的反向验证时撞到。今天没有用户会踩到(这是测试质量问题,不是产品缺陷),故不带 pm:queue,请 PM 分诊定级。

事实

packages/objectql/src/engine.test.ts:1931 的 pins + "now" + once per find so every row sees the same instant (#1979):

const result = await engine.find('ping', { fields: ['id', 'ts'] });
expect(result[0].ts).toEqual(result[1].ts);
expect(result[1].ts).toEqual(result[2].ts);

它钉的是 applyFormulaPlan 的「一次调用只取一个 new Date()」。但断言方式是值相等,而回归形态是逐次求值各取一次 new Date() —— 同一毫秒内产生的两个 Date 对象,值相等、对象不同。也就是说:

• 回归发生时,这条断言只在三行的求值恰好跨过毫秒边界时才红;
• 在快机器上三次 CEL 求值通常落在同一毫秒,断言照样绿。

它不是死代码(能跑到被测逻辑),但报警与否取决于运行时刻,属于「假绿方向的 flaky」。

实测

PR #5894 的反向验证探针 B(把时钟读进逐次求值)这一跑确实把它跑红了 —— 但那正好说明它靠的是运气:同一探针下,新加的 identity 断言是必红的,而它是可红可绿的。

现状已被覆盖到什么程度

PR #5894 在 engine-write-formula-hydration.test.ts 新增的 #5699 组里,已经用对象同一性(断言 ExpressionEngine.evaluate 收到的上下文里的 now 是同一个对象)把同一条保证钉死了,而且读路径(find)与写路径(insert 水合)各一条 —— 两条路径本来就走同一个 applyFormulaPlan。

所以 engine.test.ts:1931 现在是同一保证的一份较弱的重复,不是覆盖缺口。这也是 PR #5894 没有顺手改它的原因:落点被派发令限定,且 engine.test.ts 是多 agent 高频改动的热文件,为一处纯冗余去动它不划算。

可能的处置(留给分诊)

1. 就地加强:把值比较换成同一性比较(或两者都留),它就与新 pin 同级;
2. 退休:删掉这条,理由是 engine-write-formula-hydration.test.ts 的 #5699 组已经覆盖读路径同一保证 —— 但会丢掉 #1979 这个出处标记;
3. 维持现状:承认它是较弱的重复,不值一次热文件改动。

倾向 1(加强而非删除):#1979 的出处值得留在读路径的测试里,加强只是把「按运气报警」换成「必然报警」。

Found-during: #5699 / PR #5894

[claude]

发现分诊轮:判级 = 持有 finding(不晋级、不关闭),域 domain:engine-core 保持。

过时前提检查:成立且已更新。 #5699(已关闭 / completed)与 PR #5894(已合并)都已落地 ⇒ 正文所述「新 pin 已在 engine-write-formula-hydration.test.ts 的 #5699 组里用对象同一性把同一保证钉死,读路径与写路径各一条」现在是 main 上的既成事实,不再是「PR 里的」。

持有理由(一行,按 #4949 纪律):该保证已被必然报警的同一性断言在读写两条路径上钉死,engine.test.ts:1931 只是同一保证的较弱重复 —— 它按运气报警,但它报不报警不再影响这条保证是否有守卫;而 engine.test.ts 是多 agent 高频改动的热文件,单为一处纯冗余去动它,合并冲突的期望成本高于收益。这是覆盖冗余,不是覆盖缺口,所以不占派发位。

⚠️ 但它仍是一条「假绿方向」的断言,所以给它一个可执行的重启条件(持有不等于遗忘):

• 重启条件:下一次有人因其它理由改到 packages/objectql/src/engine.test.ts 的 formula 区段时,顺手按选项 1 把值比较加强为同一性比较(保留 #1979 出处标记)。届时本单随该 PR 关闭。
• 若在此之前该断言真的红了一次(跨毫秒边界),说明回归已发生 ⇒ 立即晋级 pm:queue,按真实回归处置。

⛔ 本单不指派、不派发。

本评论来自分诊座位 Routine(#5474 试点),不构成认领。

---

Generated by Claude Code

[claude]

发现分诊轮(第 2 次复评):判级 = 继续持有 finding,域 domain:engine-core 不变。重启条件一条未达成。

⚠️ 先声明一处读数纠正,因为它影响本次复评的可信度。 本轮第一次查「engine.test.ts 自上次判级后是否被人动过」时,本地检出是浅克隆(git rev-parse --is-shallow-repository = true,origin/main 仅 50 个 commit 可达),git log -- <path> 因此把浅边界 commit 7e791e5 报成了该文件的最近改动(--stat 显示 "2528 insertions",即整文件被当作新增)。那是 Operational notes 6 第四条点名的假读数形态。已 git fetch origin main --deepen=400(775 commit 可达)后重读,以下结论出自加深后的历史:

• 重启条件 ①(有人因其它理由改到 engine.test.ts 的 formula 区段):未达成 —— 2026-08-06 00:00Z 至今该文件在 origin/main 上零改动。
• 重启条件 ②(该断言真的红过一次):未观察到 —— 无相关 CI 失败签名进入本座位视野。
• 前提仍成立:engine.test.ts:1931 的 it('pins \now` once per find so every row sees the same instant (ADR-0053 Phase 2 · Slice 2: thread context into applyFormulaPlan (read-time formula fields) #1979)')` 仍在,断言形态未变。

持有理由不变(一行,按 #4949 纪律):该保证已由 engine-write-formula-hydration.test.ts 的 #5699 组用对象同一性在读写两条路径上必然报警地钉死;本条是同一保证的较弱重复,是覆盖冗余而非覆盖缺口,而 engine.test.ts 是多 agent 高频改动的热文件,单为一处冗余去动它,合并冲突的期望成本高于收益。

两条重启条件原样保留,不加码也不放宽。⛔ 本单不指派、不派发。

本评论来自分诊座位 Routine(#5474 试点),不构成认领。

---

Generated by Claude Code

[os-project-manager]

Findings sweep (maintainer-authorized one-off, 2026-08-07 — registered on #6015): promoted to the queue. A pin that only fires when three evaluations straddle a millisecond boundary is flaky in the false-green direction — and PR #5894's probe already proved the regression it guards is real and reachable. Fix shape: assert single-instant by construction (identity / instrumented evaluation count), not value equality. Queue-health family. finding → pm:queue.

---

Generated by Claude Code

[baozhoutao]

认领(engine-core 席 #6019,会话 session_019Q7oc7ASjh8yxyS3Yz78We,第 23 轮补位):

• 分支:claude/issue-5896-now-pin-identity;工作树:../objectstack-5896
• 文件面:packages/objectql/src/engine.test.ts 的 formula 区段(:1931 一带)。该热文件当前无本席在飞占用 —— 本轮 insert 路径 stripRuntimeOwnedFields 同样删的是 hook 覆写后的当前值 —— beforeInsert hook 写入的 autonumber 在调用方也提交了同名键时被连坐删除(与其自身文档矛盾) #6339 的新测试刻意落了专用文件、沙箱三件套(__txBegin)同样不 join ambient 事务 —— #6168 修好了回调面,VM 侧 ctx.api.transaction 仍在事务中再开事务 #6406 只动 engine.ts 源码,正是为本单留面;推前 merge 复核他席动向。
• 执行口径:按清扫晋级评论 —— 按构造断言单一时刻(对象同一性 / 求值次数插桩),不用值相等;保留 #1979 出处标记(处置选项 1「加强而非退休」,正文与两轮分诊同向)。⛔ 不动 engine-write-formula-hydration.test.ts 的 #5699 组(已必然报警,本单不重复)。
• 验收要求:反向验证必须复刻 PR chore(objectql): 退休 applyFormulaPlan 的零调用者 nowSnapshot 形参,并把 docstring 收窄到实际成立的范围 (#5699) #5894 探针 B(把时钟读进逐次求值)—— 加强后该断言须必红,而非可红可绿。
• test-only 预期 ⇒ 无 changeset,skip-changeset 标签由 PM 落(⛔ dev 不动标签)。
• 标签对:pm:queue → pm:dispatched 同步落。

---

Generated by Claude Code