You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
…loud#1652)
'+ add field' appended field_<N> to the DRAFT, and the column array is a
fetch input, so the next query named a column the server does not have —
400 INVALID_FIELD, and the whole grid became '该视图的查询被拒绝' with a
message pointing at filters that were never there.
Boundary measured on a rig, not assumed: saving the field as a draft
returns 200/state=draft and the very next select naming it still 400s.
Materialisation happens at PUBLISH, so the projection must come from the
baseline (layered().effective), which is what publishedFieldNames now
carries.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The eager closure is every chunk the entry reaches through static imports — what the browser fetches and parses before the app renders. The entry chunk on its own is a small fraction of it.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
现象
Data 支柱点一下**「添加字段」**,整个记录网格立刻变成:
现场没有任何筛选条件,所以那条建议把人带向死路。staging 上 100% 复现。
根因
gridColumns取的是草稿对象的字段名,而这个数组是下游取数的输入(ListView 按身份依赖它);addField只往本地草稿推一个field_<N>。于是:紧邻的、完全相同但不含
field_11的请求是 200。服务端行为是对的——它的错误信息专门解释了为什么不能静默丢弃未知列:那会把窄投影悄悄答成宽投影。要修的是前端的投影来源。
代码里那句注释正是错误假设:「真正的字段增删会产生新数组、因而触发它应有的重取」——新增字段的那次重取必然失败。
边界是实测的,不是猜的
在本地 rig 上问了服务端:
200,state=draftselect指名它INVALID_FIELD物化发生在发布时。所以「有没有保存」是错的问题,「服务端有没有」才是——答案在
layered().effective基线里。改动
publishedFieldNames(加载时取自基线);gridColumns只保留其中存在的列。新字段照常在右侧检查器里被选中、配置(那本来就是配置它的地方);发布之后它可查询了,才作为列出现在网格里。过滤放在列数组这一处而非取数那一侧,是为了让「网格要什么」只有一个真相源。
测试
DataPillar.gridProjection.test.tsx断言在交给对象视图的列数组上——那个数组就是投影本身。若只监视取数调用,日后在下游改一手也能通过,缺陷会悄悄搬回来。反向对照(只删那一行过滤、保留逗号):第二条精确转红、第一条仍绿。
packages/app-shell/src/views/studio-design/有约 6 条不稳定失败,main 上同样如此(单独跑均绿),与本 PR 无关。