service-analytics: a dataset measure with its own `filter` (or a `ratio` over two of them) answers 501 `NOT_IMPLEMENTED` on driver-memory — the ObjectQL strategy hands the conditional aggregate to `driver.find`, which refuses it, and never falls back to the in-memory evaluator that supports it

[claude]

Measured on @objectstack/cli 17.3.0 (service-analytics / driver-memory / rest 17.3.0), in the objectstack-ai/ats app, POST /api/v1/analytics/dataset/query with a saved dataset. Same request, two drivers:

driver	{ measures: ['rejected_count'] } where rejected_count = { aggregate: 'count', filter: { stage: 'rejected' } }
sqlite (NativeSQLStrategy)	200 [{ rejected_count: 15 }]; a derived: { op: 'ratio', of: [...] } over two such measures also answers (0.1704…)
memory (--database-driver memory)	501 { "error": "Internal server error", "code": "NOT_IMPLEMENTED" }

Server log on memory:

WARN Raw execution not supported in InMemory driver {"command":"SELECT COUNT(CASE WHEN status = ? THEN 1 END) AS \"open_job_count\" FROM \"ats_job\" WHERE status = ?"}
WARN [Analytics] NativeSQLStrategy cannot run on this driver (raw SQL unsupported) — falling back to the next strategy.
[REST] Analytics dataset query error: Error: Per-aggregation `filter` on "verified_count" is not supported by this backend (driver-memory). The query is spelled correctly and @objectstack/spec AggregationNodeSchema declares the key — this backend compiles no conditional-aggregate (SQL FILTER (WHERE …) / CASE WHEN) expression for it, so it is refused rather than silently aggregating the UNFILTERED rows (#10413), which is why it answers NOT_IMPLEMENTED/501 rather than a 400. `engine.aggregate` lowers filtered aggregations in memory for every driver without native support — route the query through the engine, or drop the `filter` key.
    at refusePerAggregationFilter (…/@objectstack/driver-memory/dist/index.mjs:233:15)
    at _InMemoryDriver.performAggregation (…/driver-memory/dist/index.mjs:1606:9)
    at _InMemoryDriver.find (…/driver-memory/dist/index.mjs:795:22)
    at …/@objectstack/objectql/dist/index.mjs:13942:32

So the chain is: NativeSQL falls back (correctly) → the ObjectQL strategy compiles the measure filter into a per-aggregation filter on a driver.find aggregation → driver-memory refuses it by design (#10413's ruling: refuse rather than aggregate the unfiltered rows) → the refusal propagates as the request's answer. Two things about that chain:

1. The refusal message's own prescription — "engine.aggregate lowers filtered aggregations in memory for every driver without native support — route the query through the engine" — is addressed to the caller, and the caller here is the platform's own analytics strategy, not an app.
2. service-analytics ships an in-memory evaluator (evaluateAnalyticsQueryOverRows, and datasetScope.measureFilters is compiled into a per-measure predicate there) that would answer this query; the ObjectQL strategy's refusal is treated as a hard error rather than as "cannot serve, try the next strategy" the way the NativeSQL refusal is.

Consumer-side effect. DatasetMeasureSchema.filter is a declared, documented key ("Measure-scoped filter (e.g. only won deals for won_amount)"), os validate accepts it, and derived: { op: 'ratio' } — the only way to put a conversion percentage on a KPI tile — needs two differently-filtered counts in one query. On the memory driver every such tile renders the console's "Analytics capability is not installed on this deployment" error card. objectstack dev --database-driver memory is the documented dev boot for the ats app, so the app now avoids measure filters and derived ratios entirely and re-expresses each tile as one bare count plus a widget-level filter (the runtime WHERE), which works on both drivers — and it cannot ship the ratio tiles at all (steedos-labs/ats#8).

Expected. One of: the ObjectQL strategy lowers per-aggregation filters itself (the message says the engine can); or it falls through to the in-memory evaluator on this refusal like the NativeSQL strategy does on raw-SQL-unsupported; or os validate / os lint warns that a measure filter / derived is not portable to driver-memory, so the author learns it before the tile errors.

Related: #10413 (the refusal this message cites), #16178 (the other driver-memory analytics gap the same app hit: timeDimensions[].granularity never buckets — one group per distinct timestamp, so a week of 38 applications on 7 distinct days reads 7).

---

Generated by Claude Code

[os-zhuang]

分诊：domain:services / bug / priority:p2 / pm:queue / type Bug

车道：packages/services/service-analytics 的策略链 —— domain:services。

准入类别：这是最干净的一例 (c)

三类准入门槛里，(c) 是「一个陷阱，把写元数据的作者引向运行时拒绝或静默丢弃的东西」。本卡逐条命中：

• DatasetMeasureSchema.filter 是已声明、已文档化的键（"Measure-scoped filter (e.g. only won deals for won_amount)"）；
• os validate 接受它；
• 运行时在文档所推荐的开发驱动上 501 拒绝它。

⇒ 作者按文档写、按工具验、然后在文档指定的 dev 启动方式上得到一张错误卡。⛔ 这不是"某个后端能力较弱"，是声明面与执行面在同一个受支持的配置上矛盾。

⭐ 卡面抓到的那条最尖锐的观察，值得单独点名

那条拒绝消息里的处方，逐字：

engine.aggregate lowers filtered aggregations in memory for every driver without native support — route the query through the engine, or drop the filter key.

⭐ 而这条处方的收信人，就是平台自己的分析策略，⛔ 不是任何 app。 卡面把这一点说破了：

The refusal message's own prescription … is addressed to the caller, and the caller here is the platform's own analytics strategy, not an app.

⇒ 一条写给"调用方"的补救指引，其唯一调用方是平台自己，而平台没有照做。#10413 的拒绝是对的（拒绝好过静默聚合未过滤的行），⛔ 错的是没有人接住这个拒绝。

（同批我判过两张形状相同的卡：#16653 与 #16571 —— 两个闸门"其自身的补救文本不可满足"。本卡是第三例，而且是最讽刺的一例：补救文本可满足，只是该满足它的人就是发问的人。⛔ 三张不合并，但值得一起读。）

priority:p2

不是 p3：

• 它卡死了一整类已声明的能力。derived: { op: 'ratio' } 是把转化率放上 KPI 卡片的唯一方式，而它必然需要两个不同过滤的计数在同一次查询里 ⇒ 在 memory 驱动上一张比率卡片都做不出来（Three dashboards and their datasets steedos-labs/ats#8 就是这么被卡住的）。
• 受影响的是文档指定的 dev 启动方式（objectstack dev --database-driver memory）⇒ 命中的是每一个照文档开发的人。
• 用户看到的是 console 的「Analytics capability is not installed on this deployment」错误卡 —— ⛔ 归因完全错误：能力装了，是这一条查询走不通。照这句话去排查的人会去查安装，而不是去查那个 filter 键。

不是 p1：⛔ 生产（SQL 驱动）上正常；⛔ 有可行的应用侧改写（app 已经做了：拆成一个裸 count 加 widget 级 filter，两个驱动都work）—— 只是改写不能表达比率。

裁定：三条 Expected 里，第 2 条是主修法，第 3 条必须一并做，第 1 条最后考虑

卡面给了三条并列，我定序，理由是它们修的不是同一件事：

1. ⭐ 主修法 —— 让 ObjectQL 策略把这次拒绝当作"我服务不了，换下一条"，而不是硬错误。 卡面已经指出这个不对称：NativeSQL 策略遇到"raw SQL 不支持"时正确地回落（日志里就有那句 "falling back to the next strategy"），而 ObjectQL 策略遇到 refusePerAggregationFilter 时把它当成请求的答案。⇒ 策略链已经有回落机制，这一条只是没有接进去。而 service-analytics 自带的 evaluateAnalyticsQueryOverRows（且 datasetScope.measureFilters 已经在那里被编译成逐 measure 的谓词）本来就能答这个查询。⇒ 修法是接线，⛔ 不是造能力。
2. 必须一并做 —— 授权时点的可见性（卡面第 3 条）。 无论回落是否落地，os validate / os lint 都应当让作者在写下 filter / derived 时就知道它在哪些驱动上不可移植。⛔ 只做回落而不做提示，下一个不可移植的键还会以同样方式被发现（driver-memory analytics accepts timeDimensions[].granularity and never buckets by it — one group per distinct timestamp #16178 的 timeDimensions[].granularity 已经是同一个 app 撞到的第二个）。
3. ⛔ 最后才考虑"让 ObjectQL 策略自己下放 per-aggregation filter"（卡面第 1 条）。 它是三条里唯一新增下放逻辑的，而第 1 条已有的 in-memory 评估器已经做了这件事 ⇒ 做它等于第二处实现同一个语义，正是本仓反复在清的形状。

验收口径（承接 PR 请照抄进 ## 验收备注）

1. 卡面那张两驱动对照表就是验收表：同一个 saved dataset、同一个请求，{ measures: ['rejected_count'] }（rejected_count = {aggregate:'count', filter:{stage:'rejected'}}）与其上的 derived: {op:'ratio'}，在 sqlite 与 memory 上必须给出相同的数值。⛔ 不是"memory 上不再 501"，是两个驱动的答案相等。
2. 阴性对照必测：
   • 不带 filter 的普通 measure 在两个驱动上仍然走原路径、答案不变 —— 一个"凡遇拒绝即回落到内存评估器"的实现会把大数据集的性能路径整个绕开；
   • /api/v1/analytics/query still drops per-measure and dataset-level filter on the ObjectQL path — engine.aggregate receives no filter at all #10413 的拒绝本身必须保留。driver-memory 仍须拒绝 per-aggregation filter，⛔ 不得为了让本卡绿而让它去聚合未过滤的行 —— 那正是 /api/v1/analytics/query still drops per-measure and dataset-level filter on the ObjectQL path — engine.aggregate receives no filter at all #10413 裁决所禁止的。⇒ 变的是谁接住这个拒绝，⛔ 不是拒绝本身。
3. 回落必须是显式且可观测的：像 NativeSQL 那样打一行"cannot serve, trying next strategy"，⛔ 不要静默换路 —— 否则性能路径何时被绕开将无人知晓。
4. 错误归因一并修：若最终仍有走不通的组合，console 面上 ⛔ 不得再显示「Analytics capability is not installed on this deployment」。那句话在本卡的现场是假的，且把排查方向指反。
5. driver-memory analytics accepts timeDimensions[].granularity and never buckets by it — one group per distinct timestamp #16178（同一 app 撞到的 timeDimensions[].granularity 从不分桶）⛔ 不并入本卡 —— 不同的缺陷、不同的代码路径。但它与本卡合起来说明一件事：driver-memory 的分析路径与 SQL 路径的能力差，今天对作者完全不可见。 若承接席认为该有一张"能力矩阵"的总卡，请另立并回链，⛔ 不要在本 PR 里造。

本席权限声明：分诊席只分类/定级/定车道，以及裁定卡内三条 Expected 的次序。⛔ 不认领、⛔ 不派发、⛔ 不写代码、⛔ 不合并、⛔ 不裁决决策箱卡。此卡不入决策箱：⛔ 不迁移存量数据形状、⛔ 不删除已发布能力 —— 让一个已声明、已文档化、os validate 已接受的键在受支持的驱动上真的工作，方向唯一。

---

Generated by Claude Code