Repository navigation
[finding] 已保存视图的 ViewFilterRule[] 被原样当 FilterNode 送进 $filter,未在客户端折成 AST #3431
Description
发现于 #3419(把 ObjectDataPage「Save as view」的 URL 下钻三元组折成 spec rule)。不在该 PR 的 fence 内,也没有在真后端上验证过,故按 observation 记录,不带 pm:queue。
观察
已保存视图的 filter 落盘形状是 spec 的 ViewFilterRule[]({ field, operator, value })—— objectstack#5159 的修法就是让 persistViewFilter 写 folded.rules。读回来时:
ObjectView.tsx(约 1347 行)const base = viewDef.filter ?? listSchema.filter,再[...baseArr, ...urlFilters]—— 这里会把 rule 对象和 URL 三元组混在同一个数组里;- 传给
ListView的schema.filter,ListView.tsx:1089交给buildEffectiveFilter; buildEffectiveFilter→mergeFilterNodes→toFilterNode(packages/core/src/utils/filter-converter.ts:199),而toFilterNode对数组是原样返回:
if (Array.isArray(source)) return source.length > 0 ? (source as FilterNode) : undefined;也就是说 [{ field: 'stage', operator: 'equals', value: 'open' }] 会被当成一个 FilterNode 直接进 $filter。客户端这一路没有任何地方把 rule 对象折成 [field, op, value](ListView.mapOperator 只在 convertFilterGroupToAST 里被调用,处理的是 FilterBuilder 的 group,不覆盖 schema.filter)。
值得注意的是 mergeFilterNodes 自己的注释就警告过这个形状:
spreading a
ViewFilterRule[]puts bare rule OBJECTS where the AST expects nodes, and the server neither understands nor rejects that cleanly ——isFilterASTsays no (a 400 since objectstack#4121), whileparseFilterASTreads the rule as a Mongo condition and filters on columns literally namedfield/operator/value.
注释是针对 spread 写的,但 toFilterNode 的原样返回把同一个数组整体交出去,落到 $filter 上是同一类载荷。
为什么标成 observation 而不是缺陷
两种可能我没能区分,需要一个跑起来的后端才能定:
- 服务端本来就接受
ViewFilterRule[]—— 那这条只是注释与实现的语气不一致,顺手补一句说明即可; - 服务端不接受 —— 那么今天每一条带 filter 的已保存视图筛选都是坏的(400 或静默按字面列名过滤)。若真如此,chore(plugin-editor): 移除被跟踪的 Vite temp-config 冻结产物 #5159 落地后应该早就被发现,所以我更倾向 1;但「早该被发现」不是证据。
复现方向(给接手的人)
起一套栈(AGENTS.md「每个 agent 独立测试栈」),在某对象上存一条带 filter 的列表视图,打开它,看网络面板里 $filter 的实际载荷与返回行数:是 [{"field":...}] 且结果正确,还是 400 / 未筛选。
相关
- objectstack#5159 / objectstack#4121(
isFilterAST的 400) - Migrate the remaining ListView legacy vocabulary to spec-canonical keys, and audit ObjectView/DetailView (#2231 phases 4–5) #2890(ListView 遗留词汇迁移)—— 同一片区域,但那条讲的是
show*与userActions,不是 filter 形状 - ObjectDataPage「Save as view」把 URL filter 三元组原样写进 ViewItem,产出过不了 ViewItemSchema #3419 / PR fix(app-shell): 把 Save as view 的 URL 下钻条件折成 spec ViewFilterRule (#3419) #3427 —— 只改了 producer 侧的写入形状,读回这一路刻意没动
Activity
yinlianghui commentedon Aug 6, 2026
发现分诊轮(晋级):摘
finding换bug+pm:queue(objectui 分片 PM,会话session_01GTRjn8xBqp75dk7kFupVRt)。前提复核 live:ObjectView.tsx:1348-1350仍混拼viewDef.filter与 urlFilters、filter-converter.ts:201数组原样透传,且 objectstack 侧parseFilterAST对「对象元素数组」返回 undefined——saved view 的过滤条件今天大概率被静默丢弃。本条是全池最重的一单;派发时第一步做跨栈实证(可用 live-e2e lane),再按 producer 侧折叠(#3427 先例)修。Generated by Claude Code
yinlianghui commentedon Aug 6, 2026
认领:objectui 分片 PM 并行批第 46 单
会话:
session_01GTRjn8xBqp75dk7kFupVRt分支:
claude/issue-3431-savedview-filter-fold-readWorktree:
objectui-issue-3431文件面:
packages/app-shell/src/views/ObjectView.tsx(读回混拼处)±packages/core/src/utils/filter-converter.ts(若裁定折叠落 core)+ 两包测试 + changeset。⛔ 不动 packages/spec 与 objectstack 仓(服务端行为只验证不修改;若实证指向服务端缺陷,按跨分片转移立单)。派发首步(决定 issue 命运):跨栈实证二选一——起独立测试栈按复现方向抓
$filter实际载荷与结果,或用 live-e2e lane 的真后端写一条带 filter 的保存视图用例。实证结论决定走「修读回折叠」(1 假 2 真)还是「补注释关单」(1 真)。修法方向沿 #3427 先例:producer/读回侧折叠成 AST,复用既有 canonical 出口,禁消费端猜测式宽容。Generated by Claude Code
yinlianghui commentedon Aug 6, 2026
验收:ACCEPT → PR #3471(并行批第 46 单,会话
session_01GTRjn8xBqp75dk7kFupVRt),已跑检查全绿(shards 收尾中),转 ready + auto-merge。复核要点:
not in(带空格),服务端 400;且它是第二张手工算子表 #3470(not_in→'not in' 二次手表映射,实测 400)已分诊bug+pm:queue;live spec 未入 allowlist 系遵守 lane 自己的防 flake 政策,晋级 chore 已另立单跟踪。Generated by Claude Code
fix(core): fold a saved view's ViewFilterRule[] into AST before it re…
fix(plugin-list): 删掉 UserFilters 的私有算子表,tab preset 走 spec 单一出口 (objec…
feat(data): surface save advisories from the second metadata client c…