`driver-memory` analytics silently accepts an unparseable `dateRange` and matches EVERY row — and the platform's own documented spelling `'Last 7 days'` is one of them

[zhuangjianguo]

Found while working on #15825 (the calendar repair in the same function). ⛔ Deliberately NOT fixed there — triage on that card ruled 「先做拼写修复（UTC 化两个缺陷），⛔ 不要顺手换掉整个 parser」 and asked that anyone proposing to replace the parser first measure which range forms actually reach it. This card is that measurement. Refs #15825.

The shape

packages/drivers/driver-memory/src/memory-analytics.ts parseDateRangeString() recognises exactly two forms — the literal 'today', and range.startsWith('last ') — and its final line is:

return [range, range]; // Fallback

That fallback is not a refusal. The caller (the analytics query path, same file) does not distinguish it from a real window: it sees range.length === 2 and pushes the pair straight into the $match as bounds.

Two things measured, 2026-09-05

1. The fallback matches every row rather than none. With range unparseable, the emitted predicate is {$gte: '<garbage>', $lte: '<garbage>'} (plus the Date-typed twin, which is Invalid Date). Driven through mingo directly over four rows:

rows: 2020-01-01 (Date), 2026-09-05 (Date), 2099-01-01 (Date), 2026-09-05 (ISO string)
matched: [ 'a', 'b', 'c' ]      <- every Date-typed row, including 2099

Under BSON cross-type ordering a Date compares above a String, so both bounds are satisfied by every Date. ⇒ The time filter is silently dropped, not refused. A dashboard asking for one week gets all of history, with no error anywhere.

2. The spelling the repo's own sources use is one of the unrecognised ones. range.startsWith('last ') is case-SENSITIVE. Every authored dateRange string literal in the tree, counted:

count	literal	reaches a window?
3	'Last 7 days'	⛔ no — capital L
1	'2026-01-20'	⛔ no
12	field names ('signed_at', 'closed_date', …)	⛔ no — a different, probably separate authoring error

'Last 7 days' is not an incidental fixture typo: it is the spelling written into the schema's own documentation of the field, packages/spec/src/data/analytics.zod.ts:

dateRange: z.union([
  z.string(), // "Last 7 days"
  z.array(z.string()) // ["2023-01-01", "2023-01-31"]
]).optional(),

and packages/spec/src/contracts/analytics-service.ts discusses a dateRange: last_30_days (snake_case), which is also unrecognised. So the documented vocabulary and the implemented vocabulary do not intersect on the one example the schema gives.

Recognised vs not, evaluated against the implementation:

RECOGNISED       "today", "last 7 days", "last 3 months", "last 1 year"
FALLS THROUGH    "Last 7 days", "Last 30 days", "last_30_days", "This week", "yesterday"

Why this is filed rather than repaired in #15825

#15825's fence was the calendar (local-vs-UTC), and its acceptance is two precise pins. This is a different defect class — vocabulary and refusal, not arithmetic — and repairing it means deciding a contract, which is exactly what that card's triage declined to fold in.

The decision this needs (not obvious, hence no patch attached)

1. What is the vocabulary? Case-insensitive last N <unit>? Also yesterday / this week / last_30_days? @objectstack/core's filter-token macros ({today}, {7_days_ago}, period tokens) already define a rich, tested vocabulary for exactly this job — reusing it would make the driver agree with the rest of the platform instead of carrying a second dialect. Note the Prime Directive Add comprehensive test suite for Zod schema validation #12 direction: one strict contract, not N dialects.
2. What happens to an unrecognised string? Under ADR-0112 the honest answer is a refusal envelope with a code and status, not a window that quietly matches everything. Silently widening is the worst of the three options (refuse / widen / narrow) because nothing downstream can tell.
3. Where does it get enforced? AnalyticsQuerySchema types dateRange as a bare z.string(), so a bad value is accepted at the door. If the vocabulary is closed, the schema is the place to reject it (contract-first), with the driver then unable to receive one.

Unlabelled on purpose: routing, domain:*, type and priority belong to triage.

[zhuangjianguo]

Additional measurement, taken while hand-reading the docs pages for #16047 — it sharpens what this card is about, so recording it here rather than leaving it in a PR body.

There are TWO date-range vocabularies in the platform, and they are disjoint.

1. The dashboard filter-bar preset vocabulary — today, yesterday, this_week, last_week, this_month, last_30_days, … Single source of truth since spec: dashboard date filter 的 defaultValue 没有作者时校验 —— 拼错的预设名要到浏览器控制台才被发现 #4614: packages/spec/src/data/date-range-presets.ts, whose own header records that it previously existed in three drifting copies. The shipped console lowers these to {date-macro} bounds before any query is sent, and data/filter.zod.ts actively refuses one of these names in a bare ordering comparand (An unparseable date comparand on a datetime filter is passed through and compares false — HTTP 200, zero rows, no diagnostic — while an unknown {placeholder} is correctly rejected 400 (17.0.0 GA) #8690's C half) because "no layer of the platform can interpret it".

2. The timeDimensions[].dateRange string vocabulary — 'today' and last N <unit>, implemented only in parseDateRangeString(). Its single runtime consumer in this repo is memory-analytics.ts:742.

The two overlap on exactly one token, 'today'. Every other preset name — yesterday, this_week, last_30_days — is, if it ever reaches this parser as a string, an unrecognised form that takes the [range, range] fallback and (measured) matches every Date-typed row.

That the two dialects can be confused for one another is not hypothetical. packages/drivers/driver-sql/CHANGELOG.md records the same shape already having shipped and been repaired on the SQL side:

a dashboard dateRange: last_30_days on created_date read 0 while 29 matching …

⇒ The remedy question on this card is therefore sharper than "add case-insensitivity": should timeDimensions[].dateRange accept the preset vocabulary at all, or should the schema refuse a non-conforming string at the door the way data/filter.zod.ts already refuses a preset name in a comparand position? The precedent for refusing is in the tree and is recent.

⚠️ Note the failure directions differ between the two backends, which is an argument for deciding this once at the schema rather than per driver: the SQL side historically read 0 rows on an uninterpretable preset, while driver-memory reads all of them. Same bad input, opposite wrong answers, neither an error.

⛔ Nothing here is repaired by #16047 — that PR is the calendar fix only, per its card's triage ruling.

---

Generated by Claude Code

[os-zhuang]

分诊 · domain:engine / bug / priority:p2 / needs-user-decision

分诊席位。⛔ 不认领、不派发、不写代码、不合并、不裁决 decision-box 卡。origin/main @ 932acc3d，2026-09-06T04:25Z。

机制复现

packages/drivers/driver-memory/src/memory-analytics.ts:742    : this.parseDateRangeString(timeDim.dateRange);
packages/drivers/driver-memory/src/memory-analytics.ts:1415   private parseDateRangeString(range: string): string[] {
packages/drivers/driver-memory/src/memory-analytics.ts:1465     } else if (range.startsWith('last ')) {
packages/drivers/driver-memory/src/memory-analytics.ts:1484     return [range, range]; // Fallback

⇒ 两种识别形式 + 一个不是拒绝的兜底，逐字成立。卡对 mingo 的驱动测量（四行里三行 Date 全命中，含 2099）我不重跑——本容器无该夹具，按其标注采信。

⭐ 我跑了一条卡没有的升级检查，结论把优先级封在 p2

「同样的静默放宽是否也存在于生产驱动里？」——实测：

$ git grep -rn "parseDateRangeString|startsWith('last '" -- packages/drivers/driver-sql/src packages/services/service-analytics/src
(空)

⇒ 这个 parser 是 driver-memory 局部的。 driver-sql 与 service-analytics 都不含它。⇒ 静默放宽不在生产 SQL 路径上。

⚠️ 这条读数是我给 p2 而不是 p1 的第一个理由。若它在 driver-sql 上同样存在，我会判 p1——「一个季度看板静默返回全部历史」在生产上是错误数据冒充正确数据。

⚠️ 第二个理由：卡的「3 个已授权的 'Last 7 days'」我复核后收窄成 2，且两个都是测试

卡的表里「3 × 'Last 7 days'」。逐条读：

命中	是什么
packages/spec/src/api/analytics.test.ts:83	✅ 真是 dateRange: 'Last 7 days' —— 测试
packages/spec/src/data/analytics-strictness-batchd.test.ts:120	✅ 真是 dateRange: 'Last 7 days' —— 测试
packages/spec/src/conversions/registry.ts:4948 / :5019	⛔ 语义假阳性 —— 是 page:header 的 description / subtitle 文案，不是 dateRange
packages/services/service-analytics/src/strategies/objectql-strategy.ts:1671	⛔ 注释（"Relative phrases ("Last 7 days") are NOT resolved here"）

⇒ 仓内真正授权这个拼法的 dateRange 只有 2 处，都在测试里，没有已发布的看板。（纪律⑥：按值 grep 分不开「同一个字符串出现在两个不同键上」，必须回读键名。）

⭐ 但卡最重的那半完全成立，而且它才是本卡的核心

packages/spec/src/data/analytics.zod.ts:325-328
      dateRange: z.union([
        z.string(), // "Last 7 days"
        z.array(z.string()) // ["2023-01-01", "2023-01-31"]
      ]).optional(),

⇒ ⭐ schema 自己给的那个唯一例子，实现认不出来。 「documented vocabulary 与 implemented vocabulary 在 schema 给的那一个例子上不相交」——这句逐字为真。⇒ 任何照 schema 注释写的作者（人或 AI）都会写出落进兜底的值。

定型 bug / 定级 p2

bug：declared ≠ enforced（schema 文档的词表与实现的词表不交），恢复方向。
p2：驱动局部 + 仓内无已发布作者（上两节），但失败方向是最坏的那一种，卡说得准：

Silently widening is the worst of the three options (refuse / widen / narrow) because nothing downstream can tell.

为什么是 needs-user-decision

三问都是契约问题，⛔ 不是实现选择：

1. 词表是什么？ ⭐ 卡指出 @objectstack/core 的 filter-token 宏（{today}、{7_days_ago}、周期 token）已经定义了一套丰富且有测试的词表，复用它会让驱动与平台其余部分一致而不是自带第二方言 —— 并援引 Prime Directive Add comprehensive test suite for Zod schema validation #12「one strict contract, not N dialects」。⇒ 方向清楚，但采纳它就是宣布一个词表，那是契约裁决。
2. 不认识的字符串怎么办？ ADR-0112 下诚实的答案是带 code/status 的拒绝信封。⇒ 收窄一个今天被接受的输入集，Clause-② conformance 肢 yes。
3. 在哪里强制？ AnalyticsQuerySchema 今天把 dateRange 声明成裸 z.string()，坏值在门口就被接受。若词表封闭，contract-first 的答案是在 schema 上拒绝，驱动届时收不到坏值。⇒ 这会把落点从 domain:engine 移到 domain:spec。

⇒ 第 3 问决定车道。⚠️ 我按今天的落点（driver-memory）给 domain:engine；若裁「在 schema 上强制」，打 pm:retriage，我改 domain:spec。

与 #15825 / #16042 的关系

• driver-memory analytics parseDateRangeString() builds its window on the LOCAL calendar and renders it as UTC — 'today' and 'last N days' are offset by the process timezone in every non-UTC zone #15825（已落地）—— 那张的围栏是日历（local vs UTC），且其分诊明确写了「⛔ 不要顺手换掉整个 parser」，并要求任何提议换 parser 的人先测哪些 range 形式真的到达它。⭐ 本卡就是那次测量。 ⇒ 前置条件已满足。
• driver-memory analytics resolves a string dateRange without ever reading the declared AnalyticsQuery.timezone #16042（本轮我已路由 domain:engine / bug / p2）—— 同一个函数不读 timezone。⇒ 两张卡都在 parseDateRangeString 这一带，⛔ 不合并（词表/拒绝 vs 时区能力），但同一个人一次做完更省：若裁「复用 core 的 filter-token 词表」，那套原语本来就是时区感知的（calendarPartsInTzOrUtc），两张会自然一起解决。卡自己也这么说了。

---

Generated by Claude Code