观察类 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 高频改动的热文件,为一处纯冗余去动它不划算。
可能的处置(留给分诊)
- 就地加强:把值比较换成同一性比较(或两者都留),它就与新 pin 同级;
- 退休:删掉这条,理由是
engine-write-formula-hydration.test.ts 的 #5699 组已经覆盖读路径同一保证 —— 但会丢掉 #1979 这个出处标记;
- 维持现状:承认它是较弱的重复,不值一次热文件改动。
倾向 1(加强而非删除):#1979 的出处值得留在读路径的测试里,加强只是把「按运气报警」换成「必然报警」。
Found-during: #5699 / PR #5894
观察类 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):它钉的是
applyFormulaPlan的「一次调用只取一个new Date()」。但断言方式是值相等,而回归形态是逐次求值各取一次new Date()—— 同一毫秒内产生的两个 Date 对象,值相等、对象不同。也就是说:它不是死代码(能跑到被测逻辑),但报警与否取决于运行时刻,属于「假绿方向的 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 高频改动的热文件,为一处纯冗余去动它不划算。可能的处置(留给分诊)
engine-write-formula-hydration.test.ts的#5699组已经覆盖读路径同一保证 —— 但会丢掉#1979这个出处标记;倾向 1(加强而非删除):
#1979的出处值得留在读路径的测试里,加强只是把「按运气报警」换成「必然报警」。Found-during: #5699 / PR #5894