Skip to content

engine-temporal-comparand-door.test.ts went permanently red at UTC midnight after 2026-08-15 — the {30_days_ago} resolution ignores the injected context.now, and the fixture pins a calendar date #8937

Description

@os-project-manager

Found while running the @objectstack/objectql suite for #8371 (branch claude/issue-8371-filter-dotted-path-verdict) shortly after 2026-08-16T00:00Z. Filed unassigned — the failing file and every code path it exercises are byte-identical to origin/main in that branch (git diff origin/main names neither), so this is a defect on main, unmasked by the calendar, not by any diff.

Measured

packages/objectql/src/engine-temporal-comparand-door.test.ts (the #8690 B-half suite, landed via PR #8808):

FAIL [#8690] the temporal-comparand door at the engine collection point
> refuses the card's comparands with code AND status, while the positive control still returns 38
AssertionError: expected '2026-07-17' to be '2026-07-16'
at src/engine-temporal-comparand-door.test.ts:164

Reproduced twice (full suite and the file alone), both after 2026-08-16T00:00Z. Every run before UTC midnight on 2026-08-15 was green — including CI on main for PR #8935's merge at 23:20Z. This is not a flake: it fails deterministically on every run from now on, on every branch.

Mechanism

The test fixes its clock and threads it through the engine call:

constnow=newDate('2026-08-15T09:00:00.000Z');// line 104
...
awaitengine.find('support_case',{where: {created_date: {$gte: '{30_days_ago}'}}},{context: { now }asnever});
...
constfloor=newDate(now.getTime()-30*86_400_000).toISOString().slice(0,10);// '2026-07-16'expect(reads[reads.length-1].ast.where.created_date.$gte).toBe(floor);// got '2026-07-17'

2026-07-17 is exactly 2026-08-16 − 30 days — the REAL clock — while the expected 2026-07-16 is context.now − 30 days. So the {30_days_ago} resolution on the engine's read path uses the process clock and never sees the injected context.now. The test was green only while the real date and the fixture date agreed, i.e. through 2026-08-15 UTC; it armed itself to fail the next day.

Two limbs, and the fix owner decides which is the defect:

  1. If context.now is contract (the door's own docblock lists now among its context: "its context is now / timezone / userId / orgId"), the macro resolution on the read path should honour it — a clock a caller cannot inject is also a clock no test can pin, which is how this fixture ended up date-armed.
  2. If context.now is not honoured by design, the test must not pretend it is: derive the fixture from the real clock (as daysAgoIso already does for seeding) or pin the resolver, not the calendar.

Either way, a test on main that goes red on a calendar date with no code change is the immediate breakage: it will fail every CI run from 2026-08-16 onward and misattribute itself to whatever PR happens to be open.

Not touched by #8371

The red assertion is the POSITIVE control ({30_days_ago} on a scalar datetime field, undotted) — the #8371 dotted-filter verdict never judges it, and the branch's diff touches neither this file nor temporal-comparand-door.ts nor the date-macro vocabulary.

Generated by Claude Code

Metadata

Metadata

Type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions