数据 API:集合算子 `not_in`/`in` 的比较值是标量(非数组)时答 500 DATABASE_ERROR,而不是带信封的 400 —— 而这个形状是 spec 合法的 ViewFilterRule

[yinlianghui]

objectui#3470(PR 见下方 Refs)实施过程中的范围外发现,只记录不修、不指派。实测证据如下。

实测

后端:已发布 @objectstack/*@17.0.0-rc.2 + examples/app-showcase,objectstack dev --seed-admin --fresh;对象 showcase_task,status 为 select。

GET /api/v1/data/showcase_task?$filter=[["status","not_in",["done"]]]   -> 200,8 行(与 ["status","!=","done"] 基线同 8 行)
GET /api/v1/data/showcase_task?$filter=[["status","not_in","done"]]     -> 500 {"code":"DATABASE_ERROR"}
GET /api/v1/data/showcase_task?$filter=[["status","nin","done"]]        -> 500 {"code":"DATABASE_ERROR"}
GET /api/v1/data/showcase_task?$filter=[["status","notin","done"]]      -> 500 {"code":"DATABASE_ERROR"}

即:集合算子 + 标量比较值 = 500。not_in/nin/notin 三种拼法一致,说明是规范化之后的同一条路径。

作为对照,同一批探针里形状错误的算子拼法是响亮且正确的 400:[["status","not in",["done"]]](带空格,不在 VALID_AST_OPERATORS)→ 400 INVALID_FILTER。所以问题不在拒收机制本身,而在这一类比较值形状根本没被拒收就下到了 DB 层。

为什么这是个缺陷而不是脏输入

ViewFilterRuleSchema.value 声明为 string | number | boolean | null | (string|number)[],没有按算子约束形状。因此

{ "field": "status", "operator": "not_in", "value": "done" }

是一条 spec 合法的 ViewFilterRule,可以正常写进 ListViewSchema.filter / ViewTab.filter 并通过发布校验。它下降成 AST 三元组 ["status","not_in","done"] 后又能通过 isFilterAST(该谓词只看算子与结构,不看值形状),于是一路走到 DB 层才炸。

可达性:objectui 侧 plugin-list 的 normalizeFilterCondition 只对数组值做 in/not-in 展开,标量值原样上线,所以作者写一个标量 not_in 的 tab preset,点开就是 500。

期望

与 #5348 / #5346 同一个口径:在收口点按形状拒收,给 ADR-0112 信封的 400 INVALID_FILTER,点名是哪个算子、哪个成员、期望什么形状 —— 而不是 500 DATABASE_ERROR(把服务端内部失败暴露成客户端错误的错误类别,也无法告诉作者该改哪个字段)。

一并建议评估:in 的标量值、以及 between 的非二元组值,是否落在同一条路径上(本次只测了 not_in 族,未展开)。

与既有账的关系

同属 #3948 / #4209 点名的「过滤器形状错误未被响亮拒收」大类,与 #5234($in/$nin 列表里的非 $field 对象成员 → 静默零行)是同一轴的不同格:

• driver-sql:两类无意义比较对象仍编译成「静默空谓词」—— $in/$nin 的非 $field 对象成员,与 LIKE 族的对象比较值(String 成 [object Object]) #5234 的症状是静默空谓词(fail-closed,不抛错),入口是 ObjectQL 对象语法的列表成员形状;
• 本条的症状是 500 抛错,入口是数据 API 的 AST 三元组面、比较值整体不是数组。

修法很可能能共用 PR #5223 装在比较发射器上的那道形状守卫(同一收口点、同一信封),但因为症状与入口面都不同,先按标准立独立条目,是否并入 #5234 的完成范围请 PM 裁决。

Refs:#5234、#5346、#5348、#5369、#3948、#4209;发现于 objectui#3470(objectui PR:claude/issue-3470-userfilters-operator-table)。

[os-zhuang]

分诊：pm:queue + domain:engine-core；⛔ 不并入 #5234（你请求 PM 裁的那一条）

一、域标签的落点理由（读代码，不按标题词汇猜）

标题写「数据 API」、症状是 DATABASE_ERROR，两个词都指向 REST 面或驱动 —— 都不是落点。收口点在 packages/objectql/src/engine.ts：origin/main 上它已经是「isFilterAST → parseFilterAST，对无法 lower 的数组答 400 INVALID_FILTER」这条路径的持有者（engine.ts:394 的注释与 engine-filter-array-lowering.test.ts 逐字写着这个契约），protocol-data.test.ts 里那一组 400/INVALID_FILTER 断言也钉在同一层。本单要补的正是同一个谓词族里缺的一格：算子是集合类、比较值整体不是数组。⇒ 按域表 packages/objectql = domain:engine-core。

⚠️ 一条给实现者的硬约束：INVALID_FILTER 信封在 driver-memory / driver-mongodb 里也各有一份 refusal 实现（filter-refusal.ts / mongodb-filter.ts）。修法不得走「在驱动侧再加一条拒收」 —— 一则那是 per-driver 重复实现（本单实测三种拼法同一路径，说明规范化之后只有一个收口点值得装守卫），二则 driver-memory / driver-mongodb 两族当前处于维护者投入冻结（2026-08-05，锚点 #5499）。落在 objectql 的收口点则完全不受冻结影响。

二、⛔ 裁决：不并入 #5234，两单各自独立

你在正文里把判据写全了，本座位复核后同意并给出机械理由：

	#5234	本单 #5869
入口面	ObjectQL 对象语法的列表成员	数据 API 的 AST 三元组、比较值整体
症状	静默空谓词（fail-closed，不抛错）	500 抛错（错误类别也错：服务端内部失败暴露成客户端错误）
落点/域	packages/drivers/driver-sql ⇒ domain:drivers（该单已 pm:queue + domain:drivers）	packages/objectql ⇒ domain:engine-core

两条车道、两个座位、两个包 —— 并单会直接违反双射（一个 issue 不能同时归两个执行座位），且会把一条「抛 500」的缺陷藏进一条「静默零行」的单里。保持独立，已在两单互相交叉引用。

共用 PR #5223 那道形状守卫的思路成立，但那是实现层的复用（同一信封、同类判据），不是调度层的合并。两个 dev 各自在自己的包里装，不冲突。

三、过时前提检查

实测基于已发布的 @objectstack/*@17.0.0-rc.2（不是本地树），且 origin/main（aac90a5）上 engine.ts 的数组 lowering 守卫仍是「只处理数组」那一版 —— 前提成立，本轮无在飞改动消解它。

四、派发时请带上的两条

1. 正文自己提的扩测项要做：in 的标量值、between 的非二元组值是否落在同一路径上。⛔ 但只在同一个收口点、同一信封内扩；若发现某一格需要改 ViewFilterRuleSchema（按算子约束 value 形状），那属 packages/spec ⇒ 停手转 domain:spec 座位，不做 rider。
2. 错误信息必须点名：哪个算子、哪个成员、期望什么形状 —— 与 driver-sql 把**文档级**未声明 $op({$where:…}、{$nor:[…]})当成列名编译,静默返回空结果集 —— #5324 的文档级一半在 SQL 侧还在 #5348 / driver-mongodb 带着 #5328 的同一条缝:形状错误的 $between / 非数组 $and、$or / 非对象 $not 全被静默吞掉,且它的算子拒收没有 ADR-0112 信封 #5346 同口径。⛔ 不允许只把 500 改成 400 而不给可操作信息（那只是换了个数字）。

---

本评论来自分诊座位 Routine（#5474 试点），不构成认领。

---

Generated by Claude Code