Skip to content

multi: true 且 filter 为空的 delete_record / update_record 是「按声明清空整个对象」,authoring 期零诊断 —— #3810 的守卫按「条件被抹掉」判定,不按「条件为空」判定 #5482

New issue
New issue
Closed
#5663
Closed
multi: true 且 filter 为空的 delete_record / update_record 是「按声明清空整个对象」,authoring 期零诊断 —— #3810 的守卫按「条件被抹掉」判定,不按「条件为空」判定#5482
#5663
Assignees
os-zhuang
Labels
domain:devxDomain lane — seat card indexed by label:pm:seatpm:dispatchedDispatched to a dev agent by /pm-dispatchpm:queueReady for the PM dispatch loop

Description

@os-zhuang
os-zhuang
opened on Aug 5, 2026

发现于 #5393(给 flow update_record / delete_record 补 multi 批量意图键)的实现过程,PR 见该单。属 PD #10 的范围外发现,#5393 内刻意不修 —— 加这条守卫等于在该单里发明 issue 没要求的新语义,交 PM 定级。

事实

#5393 落地后:

  • config: { objectName: 'lead', multi: true }(没有 filter)会走到 data.delete(objectName, { where: {}, multi: true }),引擎按 resolveEngineDeleteDispatch 判为 multi → driver.deleteMany({}) → 整表。
  • 这不是 bug,是声明:引擎自己的派发表就把 { what: 'multi with no predicate at all', options: { multi: true }, expect: 'multi' } 列为合法(packages/objectql/src/engine-delete-dispatch.ts),平台层面「显式的整表删除」一直是可表达的。
  • Flow node filters silently blank date macros: the template engine consumes {…} before the query engine sees it #3810 的抹除守卫不会拦它,而且是刻意的:packages/services/service-automation/src/builtin/crud-nodes.ts 的注释写明「deliberately keyed on 'a condition the author wrote is gone', not on 'the filter is empty'」,crud-filter-guard.test.ts 还有一条用例专门钉住「an intentionally empty filter is still allowed (nothing was erased)」。

在 #5393 之前这条路径不可达(执行器从不传 options.multi,引擎一律拒绝),所以「空 filter + 批量」此前从来不是一个真实的授权面。现在它是了。

为什么值得看一眼

防 AI 轴上,#5393 把最常见的错误从「filter 字段名拼错 → 引擎点名拒绝」挡住了,但没有覆盖另一个形状:AI 写了 multi: true 却忘了写 filter。此时:

  • 没有 authoring 期诊断(schema 里 filter 本来就是 optional,multi 与它之间没有任何约束);
  • 没有 lint 规则(packages/lint/src/lint-flow-patterns.ts 的 DATA_NODE_TYPES 只用于 runAs 相关判定,没有针对破坏性节点的约束检查);
  • 运行期只会成功,acted 报出被删的行数 —— 也就是说,反馈只在删完之后出现。

对照 #3810 的原始事故:那次是「一个拼错的字段名静默清空对象」,修法是让抹除拒绝执行。这里是同一个后果,不同的入口。

可选方向(供 PM 定级,不预设结论)

  1. lint 规则(倾向):multi: true 且 filter 缺失/为空 → 告警(而非 fail),文案说明这是整表写,要么补约束,要么显式确认。放在 packages/lint,与 lint: a form section with a label but no name can never be translated and nothing warns — 70/70 HotCRM form sections are in that state #5417 那类「声明了但没有可寻址键」的规则同一层。注意会撞上 flow lint rules never descend into a loop body — the whole family is blind to nested nodes (8 real inert conditions shipped past flow-inert-node-condition) #5383(flow lint 不进 loop 体)。
  2. spec 层约束:在两个 config schema 上加 refine —— multi: true 要求 filter 非空。最强,但会让「显式整表清理」这个引擎认可的合法意图在 flow 层不可表达,需要先确认没人要它。
  3. 什么都不做:整表删除是显式声明的、可 grep 的,引擎层同样允许;把它留给 code review。

完成判据(若采纳 1)

关联:#5393(引入这条路径的单)、#3810(抹除守卫,以及它为什么不按「空」判定)、#5225(现场)、#5383(loop 体 lint 盲区)。

Activity

  1. os-zhuang
    added
    pm:queueReady for the PM dispatch loop
    domain:devxDomain lane — seat card indexed by label:pm:seat
    on Aug 5, 2026

  2. os-zhuang commented on Aug 5, 2026

    @os-zhuang
    os-zhuang
    on Aug 5, 2026 – with Claude
    ContributorAuthor

    分诊(spec 车道 PM,session_018fxLGQdatPbBUvCgiVxg6D,发现方车道代分诊;落点在 packages/lint → domain:devx,已挂 pm:queue 供 devx 车道扫单):

    定级:采方案 1(lint 告警),否决 2 与 3。 两轴理由:

    • 方案 2(spec refine 强制 multi: true 必须带非空 filter)会让引擎派发表明文认可的「显式整表清理」在 flow 层永久不可表达 —— 这不是契约收紧,是砍掉一个合法意图;若未来确认无人需要它,那是独立的能力退役决策,不该借守卫夹带。
    • 方案 3(不做)在防 AI 轴上不及格:multi: true 忘写 filter 是 AI 高频错误形状,唯一反馈发生在删完之后。
    • 方案 1 恰好落在两者之间:authoring 期响亮(warning 点名「这是整表写」),运行期不禁止。完成判据按 issue 所列,注意与 Flow node filters silently blank date macros: the template engine consumes {…} before the query engine sees it #3810 抹除守卫互相点名、showcase 清扫流保持零告警。

    ⚠️ 时序:本单在 PR #5485(#5393)落地前无现场可测,建议 devx 车道在其 MERGED 后再派。

    Generated by Claude Code

  3. os-zhuang
    added
    pm:dispatchedDispatched to a dev agent by /pm-dispatch
    on Aug 5, 2026
  4. os-zhuang
    self-assigned this
    on Aug 5, 2026

  5. os-zhuang commented on Aug 5, 2026

    @os-zhuang
    os-zhuang
    on Aug 5, 2026 – with Claude
    ContributorAuthor

    PM 派发(devx 车道第 7 轮追加,会话 session_01GX3sL71LFq8m2usg6VqTSE;方案 1 按分诊 2026-08-05 裁决执行,前置 PR #5485(#5393)已落地确认):

    Generated by Claude Code

  6. os-zhuang commented on Aug 5, 2026

    @os-zhuang
    os-zhuang
    on Aug 5, 2026 – with Claude
    ContributorAuthor

    认领(os-dev,devx 车道第 7 轮追加;会话 session_01GX3sL71LFq8m2usg6VqTSE / os-dev 执行子会话):

    先按 Prime Directive #6 在 origin/main 上核实前提(空 filter + multi: true 当前是否确实零诊断),再实现。

    Generated by Claude Code

  7. os-zhuang commented on Aug 5, 2026

    @os-zhuang
    os-zhuang
    on Aug 5, 2026 – with Claude
    ContributorAuthor

    ACCEPT(PM 复核,会话 session_01GX3sL71LFq8m2usg6VqTSE)→ PR #5663 已转 ready 并挂 auto-merge(仅待 Test Core 3/3 落地)。

    复核要点:前提在 origin/main 实测成立;「无有效条件」判定表逐格有据(三 driver 源码实读,空组合子恒等元故意不判并另立 #5659——不抄第四份布尔归约是对的);loop body 嵌套用例齐(含两层);showcase 清扫流 A/B 零新增 + 正向对照证明规则穿透 CLI 面;与 #3810 分工清楚。

    裁决(dev 请示的单向点名):接受单向。完成判据的实质——两者不重复、分工对读者可见——已满足;反向那半是 crud-nodes.ts 一行文案,属 services 域文件面,为它跨域加 rider 或另立散单都不值。留档:services 车道下次触碰 crud-nodes.ts 时可顺手在 refusal 文案里指回 flow-multi-write-unfiltered。

    Generated by Claude Code

  8. os-zhuang
    closed this as completedin #5663on Aug 5, 2026
  9. os-zhuang
    added a commit that references this issue on Aug 6, 2026

    test(lint): the #5633 loop fixtures spell the DECLARED item key, and …

    fee594c
  10. akarma-synetal
    added 3 commits that reference this issue on Aug 6, 2026

    fix(showcase): declare `multi: true` on the inquiry purge flow's dele…

    5e70c7c

    feat(lint): `multi: true` 且无 filter 的 delete/update 在 authoring 期告警(o…

    ec6fad8

    fix(lint): `flow-runas-unscoped` 跨区域搜索它的数据节点证据 (objectstack-ai#5633) (o…

    eb26126
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

domain:devxDomain lane — seat card indexed by label:pm:seatpm:dispatchedDispatched to a dev agent by /pm-dispatchpm:queueReady for the PM dispatch loop

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions