Flow start conditions carry no has() guards — measure whether the abort-and-skip class of #630 reaches them

[os-zhuang]

Found while implementing #630. Narrowed by the PM on 2026-08-02: the sharing-rule half of this issue is closed by measurement (see below) and only the flow-start-condition half remains open.

Settled: sharing rules must NOT get has() guards

The original suggested work said "if either surface is exposed, add has(...) guards". For sharing rules that is now known to be actively harmful. Measured in #621 / PR #637 with the platform's own compileCelToFilter — the function plugin-sharing calls at seed time:

has(record.type) && record.type == "customer"   →   unsupported operator "call"

Sharing conditions are compiled to pushdown filters stored in sys_sharing_rule.criteria_json, not interpreted per record. Function calls as a class are outside the translatable subset. So adding a has() guard to a sharing rule makes it untranslatable, which makes the seeder skip it — turning seeded: 9, skipped: 0 into seeded: 0, skipped: 9, with the same quiet signature as the bug #621 was filed for, amplified from 2 rules to 9.

Further, sharing rules likely need no totality guard at all: a missing column in a where clause is NULL-compared by the database, not an abort. The abort behaviour belongs to the CEL interpreter, and sharing conditions never reach it.

This conclusion is pinned as an assertion in test/sharing-seeding.test.ts, so an attempt to add guards there turns CI red rather than shipping inert rules.

Still open: flow start conditions (9)

case_escalation, case_escalation_on_create, opportunity_approval, opportunity_approval_on_create, lead_assignment.check_hot, case_csat_followup, contact_welcome, opportunity_won_alert, task_urgent_alert — all read record fields with no has(...).

Whether that matters is unmeasured, and must not be inherited from either of the other two surfaces. The validation path aborts and skips; the sharing path compiles to SQL and never interprets. Flow start conditions are a third mechanism and could behave like either, or neither.

What to establish:

1. What record shape does a record-change trigger hand the start condition — the driver's post-write row (sparse on driver-memory / driver-mongodb), a re-read, or a merged {...previous, ...data}?
2. Are start conditions interpreted or compiled? If compiled to a filter like sharing rules, guards are wrong here too, for the same reason.
3. What happens on abort — does the flow silently not run (the same declared-≠-enforced shape), or does it error visibly?

Suggested work

1. Measure (1)–(3) against driver-memory, which is already sparse and reproduces the condition without any setup.
2. If flows are exposed: add has(...) guards in the two shapes Script validations are silently SKIPPED when the merged record lacks the field key (update path) #630 settled on, and extend the sweep in test/object-validation-predicates.test.ts to cover flow start conditions.
3. If they are not exposed: change nothing, and record why — a comment naming the record shape and evaluation mechanism the flow path actually uses — so the next person does not re-measure it. A correct "no action needed, here is the evidence" outcome is a complete result for this issue, not a failure.

Background (from #630)

Strict CEL aborts the whole predicate on a key that is not present. Note record.f != null aborts too — the != null guards already in the repo protect against dyn< null > < int, not against an absent key.

predicate	key absent	key present as null
isBlank(record.f)	abort	true
record.f != null	abort	false
record.f == "v"	abort	false
has(record.f)	false	true

driver	absent column comes back as
@objectstack/driver-sql	key present, null
@objectstack/driver-sqlite-wasm	key present, null
@objectstack/driver-memory	key absent
@objectstack/driver-mongodb	key absent

[os-zhuang]

实测证据,来自 #621 / PR #637(本轮没有碰守卫,只是量了一下翻译器):

has() 在 sharing rule 的条件里编译不过。 用平台自己的 compileCelToFilter(即 plugin-sharing 播种时调用的函数)测:

compileCelToFilter('record.type == "customer"')                    -> ok
compileCelToFilter('has(record.type) && record.type == "customer"') -> FAIL
    reason=unsupported  detail=unsupported operator "call"

这对本 issue 的方案选择是决定性的:sharing rule 的条件不是被解释执行的,而是被编译成可下推的查询过滤器({"billing_country":{"$in":[…]}})后存进 sys_sharing_rule.criteria_json。函数调用整体不在这个子集里——has() 只是其中一个例子。

所以按 #630 给 validation predicate 用的那套 has() 写法直接照搬到这 9 条 sharing rule 上,会让每一条被守卫的规则变成不可翻译,plugin-sharing 随即拒绝播种——正是 #621 的缺陷(两条区域规则被静默丢弃、na_sales_team / eu_sales_team 什么都拿不到),只不过从 2 条放大到 9 条。而且失败方式一样安静:一行启动期 WARN,seeded: 0, skipped: 9,界面上没有任何提示。

顺带一提:sharing rule 这一层的 fail-open/fail-closed 问题,和 validation predicate 那一层性质不同。validation 是逐条记录求值,记录形状缺键会 abort;sharing criteria 是下推到数据库的 where,不存在"某条记录求值不出来"这回事——列缺失就是 NULL,不匹配而已。也就是说 sharing 侧的 totality 问题可能根本不需要守卫,需要的是别的东西(例如"规则引用的字段必须真实存在")。

flow 起始条件那一半没有测,那条路径大概率是解释执行(不是 compileCelToFilter),结论未必相同——两半要分开验证,别把 sharing 的结论套到 flow 上,也别反过来。

这个矩阵已经作为断言钉在 test/sharing-seeding.test.ts 里(sharing conditions cannot use has() + nested paths into a composite value do not compile),所以 #633 落地时如果加了 has(),CI 会直接红,而不是等到有人读启动日志。

---

Generated by Claude Code

[os-zhuang]

认领:PM 循环第 7 轮
会话:session_019SS7C5SXpniKeCApxgARyf
分支:claude/issue-633-flow-condition-totality
Worktree:hotcrm-issue-633

本 issue 已由我收窄(标题与正文已改):sharing rule 那一半因 #637 的实测而关闭——has() 在 sharing 条件里编译不过,加守卫会让 9 条规则全部变成不可翻译、被静默跳过,是把 #621 的缺陷放大而不是修复。本轮只做 flow start condition 这一半,不要碰 src/sharing/。

"测完发现不需要改"是本 issue 的合格结果,不是失败。 如果实测证明 flow 路径不暴露(比如条件也是编译成过滤器、或者拿到的是重新读取的完整行),就一行代码都不要改,把为什么写成注释固化下来——记录清楚这条路径拿到的记录形状与求值机制,让下一个人不必重新量一遍。我不希望看到为了"有产出"而加一批无用的守卫。

三件必须分别量、不能从另外两个面继承结论的事,正文里已列:记录形状(驱动的写后行?重新读取?merged?)、求值机制(解释执行还是编译成过滤器)、abort 后果(静默不跑还是显式报错)。验证用 driver-memory,它本来就是稀疏的,不需要任何额外搭建就能复现。

同批的 #638 归属 src/data/index.ts 与种子数据,与你的落点(src/flows/、test/)互斥。

---

Generated by Claude Code