Filing gate: ① a defect with a named landing site: @objectstack/core's resolveFilterTokens (packages/core/src/utils/filter-tokens.ts: asYmd over an invalid Date, and toISOString of one). Finding class (a). reach: POST /api/v1/data/:object/query on InMemoryDriver and SqlDriver (SQLite), measured by #20844's dev on PR #21065's branch (os-dev-report 5924544832 on #20844, out_of_scope_findings[0]). That branch does not change this path.
Filed by the domain:engine execution seat 2 (seat post #20966, session_01Ujdtvqs7ree7WyQmEDwEnG, os-litant). ⛔ Filed bare: routing and grading belong to triage. ⛔ Not a claim.
What happens
The fixture is #20844's: a datetime field opened_at and two rows, one in 2026 and one in 1500.
where |
answer |
right answer |
opened_at $lt {300000_years_ago} |
200, both rows |
a refusal (or none) |
opened_at $lt {99999999999999999999_minutes_ago} |
500 INTERNAL_ERROR (an uncoded RangeError: Invalid time value) |
a refusal |
- A day-or-coarser macro resolves to the literal text
Invalid Date, which no range check and no door reads. It then compares as text.
- A sub-day macro throws inside
resolveFilterTokens, from toISOString of an invalid Date. The error carries no ADR-0112 code.
This is the same family as #20844 (a token resolving outside the column's years). The mechanism differs: the instant is past what a JS Date holds at all, so #20844's year-range judge (PR #21065) never sees a year to judge.
Scope for whoever takes it (⛔ not a ruling)
Dedupe
mcp__github__search_issues, repo-scoped, open and closed, query "date macro placeholder offset beyond JavaScript Date range Invalid Date RangeError Invalid time value 500 years_ago". It returned 2 hits, neither this:
Filing gate: ① a defect with a named landing site:
@objectstack/core'sresolveFilterTokens(packages/core/src/utils/filter-tokens.ts:asYmdover an invalidDate, andtoISOStringof one). Finding class (a).reach:POST /api/v1/data/:object/queryonInMemoryDriverandSqlDriver(SQLite), measured by #20844's dev on PR #21065's branch (os-dev-report5924544832 on #20844,out_of_scope_findings[0]). That branch does not change this path.Filed by the
domain:engineexecution seat 2 (seat post #20966,session_01Ujdtvqs7ree7WyQmEDwEnG,os-litant). ⛔ Filed bare: routing and grading belong to triage. ⛔ Not a claim.What happens
The fixture is #20844's: a
datetimefieldopened_atand two rows, one in 2026 and one in 1500.whereopened_at$lt{300000_years_ago}opened_at$lt{99999999999999999999_minutes_ago}INTERNAL_ERROR(an uncodedRangeError: Invalid time value)Invalid Date, which no range check and no door reads. It then compares as text.resolveFilterTokens, fromtoISOStringof an invalidDate. The error carries no ADR-0112 code.This is the same family as #20844 (a token resolving outside the column's years). The mechanism differs: the instant is past what a JS
Dateholds at all, so #20844's year-range judge (PR #21065) never sees a year to judge.Scope for whoever takes it (⛔ not a ruling)
Date. It uses the code the token family already uses for an unresolvable placeholder (FILTER_TOKEN_UNRESOLVEDor the door'sINVALID_FILTER; measure which reads true), and names the token. ⛔ It never emitsInvalid Datetext, and never throws uncoded.{8000_years_from_now},{2027_years_ago}) reaches the driver as extended-year text and matches every row: the comparand door runs before token resolution #20844), which edits the same resolver's spelling.Dedupe
mcp__github__search_issues, repo-scoped, open and closed, query "date macro placeholder offset beyond JavaScript Date range Invalid Date RangeError Invalid time value 500 years_ago". It returned 2 hits, neither this:dateRangetokens.