data: unsupported-filter-operator refusal ships without error.code and leaks the [sql-driver] prefix

[baozhoutao]

Found while verifying the 17.0.0-rc.1 checklist on #3909 (F3). Verified on main @ 1ee48bc60.

The #4209/#4029 posture itself works — a filter carrying an operator the driver cannot compile is refused instead of matching everything. But the refusal envelope breaks the ADR-0112 contract this train shipped:

GET /api/v1/data/showcase_task?filter={"title":{"$bogusop":"x"}}
→ 400 {"error":"[sql-driver] Unsupported filter operator \"$bogusop\" on field \"title\". Supported operators: $eq, $ne, …"}

• No code at all — the body's only key is error. ADR-0112 (feat(spec,core,runtime,docs)!: ADR-0112 batch 1 — one error-code vocabulary, SCREAMING_SNAKE, schema-enforced (#3841) #3988, refactor!: ADR-0112 batch 2 — sweep the lowercase error-code emitters (#4003) #4021) made error.code the schema-enforced, SCREAMING_SNAKE vocabulary; refactor(types,rest,services,plugin-sharing): one shared writer for the response envelope, and error.code is enforced at compile time (#3973) #4229 even enforces error.code at compile time for the shared envelope writer. Sibling refusals on the same route already comply (INVALID_FIELD, INVALID_FILTER, BATCH_TOO_LARGE, RECORD_NOT_FOUND).
• The [sql-driver] internal prefix leaks into the client message — driver-internal wording on the wire is what the analytics /query 未做 cube 存在性校验,未注册名直达驱动当表名;且错误路径原样回显驱动 SQL(#3770 同类,另一子系统) #3867 sanitiser exists to stop.

Contrast: the same request with a non-AST filter array gets a proper {"code":"INVALID_FILTER"}; only the unsupported-operator branch bypasses the envelope (the driver's thrown message is served raw).

Expected: the unsupported-operator refusal speaks a catalogued code (INVALID_FILTER fits) with the actionable operator list kept in the message/details, and no driver prefix.

Part of the #3909 rc.1 verification (section F3).

[baozhoutao]

Tracked under the v17 verification tracker #3909 (section F, rc.1 run 1).

[baozhoutao]

Rolled up in #4482 (all 17 defects from the v17 verification, grouped by severity with a suggested RC-exit triage).

[os-zhuang]

交接说明（进行中 / WIP）

分支：claude/v17-verification-defects-gnf9e6-data-envelope
提交：cb1e01e wip(drivers): give the uncompilable-filter refusal an ADR-0112 code and drop the driver prefix (#4436)

已完成（代码改动本身已完整）

读完 docs/adr/0112-error-code-vocabulary-and-ledger.md 后确认：这条不是 posture 问题（#4209/#4029 的拒绝行为是对的），而是拒绝信封没有身份。根因在 mapDataError（packages/rest/src/rest-server.ts）的兜底分支：driver 抛的是裸 Error，没有 code / status，于是走到最后一行 { status: 400, body: { error: raw } } —— 只有 error，没有 code，而且 driver 自己的 [sql-driver] 前缀原样上了线。

按契约优先（PD #12）在抛出点修，没有在 rest 消费端加兜底：

• packages/plugins/driver-sql/src/sql-driver.ts 新增 unsupportedFilterError(message)，打上 code = StandardErrorCode.enum.INVALID_FILTER（从 spec 目录取常量，不硬编码字符串）+ status = 400，消息里去掉 [sql-driver] 前缀，保留可操作的「算子 / 字段 / 支持的算子表」。
• packages/plugins/driver-memory/src/memory-driver.ts 同步同一个形状。A filter with an operator outside VALID_AST_OPERATORS is silently dropped, not rejected — single-condition views return unfiltered results #3948 让两个 backend 在「不可编译的 filter 必须拒绝而不是静默全匹配」上达成一致，那么它们的拒绝信封也必须一致，否则换 driver 跑的套件会看到两种答案。
• 覆盖面：两个 driver 里所有 filter 编译期拒绝（不支持的算子 ×3、比较三元组里的非法逻辑词、非法 filter 元素类型、between 操作数不是二元数组），不只 issue 点名的那一条 —— 它们是相邻几行上的同一个信封缺陷，只修一条等于把同样的 bug 留在隔壁。

副作用（正向）：status = 400 + code 让这条拒绝命中 isExpectedQueryRejection，客户端错误不再被记成 [REST] Unhandled error。

当前卡在哪

算力额度可能耗尽，先把改动推到远端，所以这条以 wip: 提交。代码改完了，验证没做完。

下一步具体该做什么

1. 补回归测试（这条必须有，目前完全没写）：
   • packages/plugins/driver-sql/：断言抛出的 error 带 code === 'INVALID_FILTER'、status === 400，且 message 不含 [sql-driver]；
   • packages/plugins/driver-memory/：同上（不含 [driver-memory]）；
   • REST 层信封测试：GET /api/v1/data/<obj>?filter={"title":{"$bogusop":"x"}} → 400 且 body 带 code: "INVALID_FILTER"。
   • 注意现存测试 sql-driver-filter-no-silent-drop.test.ts / memory-filter-ast-vocabulary.test.ts 断言的是 /Unsupported filter operator "…"/，不含前缀，所以不会被这次改动打破 —— 但要跑一遍确认。
2. 闸门：pnpm --filter @objectstack/driver-sql test、pnpm --filter @objectstack/driver-memory test、pnpm --filter @objectstack/rest test、pnpm typecheck，外加 pnpm check:error-code-casing 和 pnpm check:route-envelope。
3. 真实启动验证（用户明确要求）：pnpm dev -- --fresh -p 38103，跑 issue 原文那条 curl：
   GET /api/v1/data/showcase_task?filter={"title":{"$bogusop":"x"}}
   确认返回 400 {"error":"Unsupported filter operator \"$bogusop\" …","code":"INVALID_FILTER"}，且不再出现 [sql-driver]。完事 kill $(lsof -ti tcp:38103)。
4. 提交信息从 wip: 改成 fix:（可以 amend 或追加一个补测试的 commit）。
5. 与本卡其余五个缺陷（data: created_at is client-writable on an ordinary PATCH — the audit anchor can be forged silently #4447 / data: PATCH/DELETE of a nonexistent record answer 200 success instead of RECORD_NOT_FOUND #4435 / data: a lookup accepts an id that does not exist in the referenced object — including the RBAC permission-set link tables #4441 / actions: sandbox capability denial answers 400 as a deliberate rejection, not the 500 the crash contract promises #4431 / $search 自动字段集：nameField/name/title 被无条件前置，绕过 SEARCH_AUTO_EXCLUDED_FIELDS——搜索会打到主键 #4483）一起开草稿 PR 打到 main。

顺带记录的越界发现（PD #10，未处理）

packages/services/service-analytics/src/strategies/filter-normalizer.ts:207 有同类的 [analytics] Unsupported filter operator …，走的是 /analytics 路由、另一个 owner，本卡不动。若确认它也裸奔无 code，建议单开 issue。

---

Generated by Claude Code