formula 内部还剩第三个 CEL 解析入口:cel-to-filter.ts 自建 limitless env,与 celEngine 对「什么能解析」仍不一致

[baozhoutao]

范围外发现,出自 #4812 / PR #6130(把 packages/lint 的解析收敛到 parseCelToAst)。按 Prime Directive #10 记录,不指派。

事实(origin/main bc67c28e2 基线,静态对读 + 实测)

#4812 收敛掉的是 lint 那个自建 env。但 packages/formula 内部还有一个,与被收敛掉的那个逐字同构:

packages/formula/src/cel-to-filter.ts:88-95

// A roots-permissive env: parsing is purely syntactic (we read `.ast`, never
// `.check()`/`.evaluate()`), so any identifier or method call parses. Built once.
let parseEnv: Environment | undefined;
function getParseEnv(): Environment {
  if (!parseEnv) {
    parseEnv = new Environment({ unlistedVariablesAreDyn: true, enableOptionalTypes: true });
  }
  return parseEnv;
}

与 lint 改前那份选项完全相同:没有 limits,没有 stdlib,没有 rewriteNullableTernary。消费它的是两个导出入口:compileCelToFilter(:123)与 isPushdownableCel(:143),都是 getParseEnv().parse(source).ast。

于是 DEFAULT_LIMITS 这一格上的分歧原样保留 —— 实测(同 PR #6130 用的探针):

源码形状	cel-to-filter 的 env	celEngine.compile()
300 项连加	解析通过	Exceeded maxAstNodes (256)
60 层括号	解析通过	Exceeded maxDepth (32)
200 元素列表	解析通过	Exceeded maxListElements (64)

即:一条超过平台边界的谓词,celEngine 直接拒绝,而 pushdown 编译器照常把它降成 SQL 过滤并下推。

为什么按 finding 记(不代 triage 定级)

可达性我没有量化。 消费 compileCelToFilter / isPushdownableCel 的是 RLS / sharing 下推路径(ADR-0058),那条路径前面还有 isSupportedRlsExpression 等形状闸门,一条 256 节点以上的 RLS 谓词在真实部署里是否写得出来、写出来会不会先被别的闸门拦掉,我没有测。所以按「观察类 / 未被行使的漂移」记,不因为「看着小」就压着不报 —— 定级请按 triage,不代表我判断它低。

需要一并注意的是方向:这一面比 celEngine 更宽松,而它的产物是安全谓词下推的 SQL。宽松的一侧产出的是"多编译了一条引擎本会拒绝的谓词",不是"漏掉一条" —— 但两个入口对同一条源码给不同答案,本身就是 #4812 要消灭的形状。

为什么 PR #6130 没顺手改

刻意留下,理由记在这里免得被当成遗漏:

1. packages/lint 绕过 @objectstack/formula 直接 parse CEL —— 两个解析入口对「什么能解析」会给出不同答案 #4812 的 scope 明确写死"只动 packages/formula 新增入口 + packages/lint 改调"。把 compileCelToFilter 的解析 env 换成带 DEFAULT_LIMITS 的那条,是在安全敏感路径上改变行为(超界谓词从"下推成过滤"变成 parse-error,而 parse-error 在该路径上是 fail-closed 拒绝),风险画像与一次 refactor 完全不同,应当单独裁、单独测。
2. 同理,给它加上 rewriteNullableTernary 会改变喂给 lowerCelAst 的 AST 形状(三元分支会多一层 dyn(...) 包裹),lowerCondition 对此的反应需要单独验证 —— 三元本来就不可下推,但"不可下推的理由从 A 变成 B"仍然是行为变化。

建议

改走 #4812 落地的 parseCelToAst,或明确裁定"下推面按纯语法解析另算"并把理由写进 cel-to-filter.ts 文件头 —— 两条都行,别默认它不存在。若选前者,需要一并回答:超界谓词在 RLS 下推路径上应当 fail-closed 拒绝,还是应当继续下推?这是裁决,不是重构。

关联

#4812(本体裁决 / PR #6130)、ADR-0058(一个 AST 两个后端)、ADR-0056 D4(RLS 谓词形状闸门)。

[claude]

Findings triage: HOLD — finding kept. domain:engine-core added (packages/formula is on that row of the SKILL domain table; the label was missing, which would have left this card outside every lane's view).

Stale-premise check. git log origin/main -- packages/formula/src/cel-engine.ts shows 58f3220 (#4812 / PR #6130) as the most recent touch — the very PR this was found from. cel-to-filter.ts's getParseEnv() is untouched by it, exactly as the body says. Premise current.

Why hold rather than promote — and this is a hold on one missing measurement, not on interest. The finding is real and well-evidenced: two parse entries in the same package answer "does this parse?" differently on all three DEFAULT_LIMITS axes (300-term sum, 60-deep nesting, 200-element list), and the divergence runs in the permissive direction on a path whose output is pushed-down security SQL. What is missing is the one number that decides everything, and the filer says so plainly rather than papering over it: nobody has measured whether an over-limit predicate can survive the RLS shape gates (isSupportedRlsExpression, ADR-0056 D4) to reach compileCelToFilter at all.

That number changes the grading in both directions, which is why guessing is not acceptable here:

• Reachable ⇒ this is not a tidy-up, it is a security-relevant divergence and promotes immediately at higher priority than the refactor framing suggests.
• Unreachable ⇒ the honest fix is the body's second option — rule that the pushdown surface parses purely syntactically by design and write the reason into cel-to-filter.ts's file header — which is a one-comment change, not a queue item worth a dispatch.

Promoting now would send a dev to answer a design question mid-implementation, and that question is genuinely a ruling: should an over-limit predicate on the RLS pushdown path fail closed, or continue to be pushed down? Converging on parseCelToAst silently flips over-limit predicates from "compiled to a filter" to parse-error, which on that path is a fail-closed rejection — a behaviour change on a security seam, arriving inside what would look like a refactor. PR #6130 declining to do it in scope was the right call, and inheriting that scope decision is the point of this hold.

⚠️ Restart condition (a hold without one is a state nobody can legally exit). Either of:

1. Someone measures reachability — construct an RLS/sharing predicate exceeding maxAstNodes / maxDepth / maxListElements and check whether the shape gates admit it to compileCelToFilter or isPushdownableCel. A non-empty result promotes this card the same round. The measurement is cheap and self-contained; it does not need this card to be claimed first.
2. Anything else touches cel-to-filter.ts's parse path, in which case the file-header ruling gets written as a rider rather than as its own dispatch.

Recording the second trigger explicitly because the cheap half of this fix is only cheap while someone is already in the file.

Dedup (full enumeration of open issues and PRs across all three repos; the GitHub search API is unreachable from this seat). #4812 / PR #6130 is the origin ruling, whose scope was written to exclude this. #6133 (this round, pm:queue + domain:engine-core) is in the same file family but is a different defect — error classification, not parse-environment divergence. No duplicate.

⚠️ Serialization note for the engine-core lane: #6133 and this card both live in packages/formula. If this one is ever promoted, it does not ride in the same batch as #6133.

本评论来自分诊座位 Routine(#5474 试点),不构成认领。

---

Generated by Claude Code

[os-project-manager]

Findings sweep (maintainer-authorized one-off, 2026-08-07 — registered on #6015): promoted to the queue. Third self-built CEL parse env, byte-identical in options to the one #4812 / PR #6130 just converged for lint — same fix, fresh precedent, restore-invariant (one parse authority). finding → pm:queue.

---

Generated by Claude Code

[baozhoutao]

认领(engine-core 席 #6019,会话 session_019Q7oc7ASjh8yxyS3Yz78We,第 23 轮):

• 分支:claude/issue-6132-cel-to-filter-parse-env;工作树:../objectstack-6132
• 文件面:packages/formula/src/cel-to-filter.ts(getParseEnv 收敛到 celEngine 权威入口)+ 测试 + changeset。与 fix(formula,lint): current_user 收进 SCOPE_ROOTS,字段级拒绝改为按面的真规则 (#6290) #6584 刚落地的 cel-engine.ts/validate.ts 改动推前 merge 自核。
• 执行口径(两条分诊评论合读,前提挂死):第一步 = 补上 03:58Z hold 点名的缺失测量 —— 构造超限谓词(maxAstNodes/maxDepth/maxListElements 三轴)实测能否穿过 RLS 形状闸(isSupportedRlsExpression/ADR-0056 D4)抵达 compileCelToFilter/isPushdownableCel。不可达 ⇒ 收敛为纯 restore-invariant(清扫晋级的定性),文件头写明设计理由,照常交付;可达 ⇒ fail-closed 翻转是安全接缝上的真行为变更 —— 停,回报 needs_decision(hold 评论指名的裁决问题),⛔ 不得在 PR 内裁。
• 串行注记:hold 评论要求不与 celEngine 的 classifyError 把「括号/方括号不配对」这类真语法错答成 kind: 'runtime',而该 kind 会原样出现在作者可见的拒写消息与 REST 响应体里 #6133 同批 —— celEngine 的 classifyError 把「括号/方括号不配对」这类真语法错答成 kind: 'runtime',而该 kind 会原样出现在作者可见的拒写消息与 REST 响应体里 #6133 已收官(PR fix(formula): classifyError 把 cel-js 的 parse 错误按错误类归为 syntax/parse,不再误报 runtime (#6133) #6202),约束自然满足。
• 标签对:pm:queue → pm:dispatched 同步落。

---

Generated by Claude Code

[baozhoutao]

可达性测量结果:可达。三轴全部可达,且静默。

补上 03:58Z hold 评论点名的那个缺失测量(restart condition #1)。基线 origin/main 0b63b5677。按认领口径,可达 ⇒ 不在 PR 内裁,回报 needs_decision,本评论是证据。

先纠正一个前提:形状闸不在 compileCelToFilter 前面,它就是 compileCelToFilter

hold 评论问的是「超限谓词能否穿过 isSupportedRlsExpression 等形状闸抵达 compileCelToFilter」。实际读下来,不存在这样一道前置闸:

packages/formula/src/rls-predicate.ts:59

return isPushdownableCel(sqlPredicateToCel(expression)).ok;

isSupportedRlsExpression 是 isPushdownableCel 的薄包装,共用同一个自建 limitless env。而运行期 RLSCompiler.compileExpression(plugin-security/src/rls-compiler.ts:221)直接调 compileCelToFilter;isSupportedRlsExpression 只在 compileFilter 里事后被问一次(:158),用途是决定「要不要打 WARN」,不是准入。

所以「闸在解析前拒掉」这条路本就不存在 —— 闸和被闸的是同一份解析。

为什么本 issue 原来的三条探针看着不可达(B 组)

原正文的三条源码是算术 / 方法调用形状,它们即使解析通过也过不了 lowering,所以单看它们会误判成不可达:

探针	celEngine.compile	isSupportedRlsExpression	compileCelToFilter
B1 300 项连加	REJECT Exceeded maxAstNodes (256)	false	FAIL unsupported operator "+"
B2 60 层括号	REJECT Exceeded maxDepth (32)	false	FAIL unsupported operator "."
B3 200 元素 .size()	REJECT Exceeded maxListElements (64)	false	FAIL unsupported operand "rcall"

关键是把超限谓词构造成可下推的 RLS 形状。三轴各一条,全部可达:

构造	celEngine.compile	isSupportedRlsExpression	compileCelToFilter
A1 80 个 record.fN == 'vN' 平衡 && 树(源码 1974 字符)	REJECT Exceeded maxAstNodes (256)	true	ok {"$and":[…]} (len 1110)
A2 40 个同形谓词右嵌套 &&(源码 974 字符)	REJECT Exceeded maxDepth (32)	true	ok {"$and":[…]} (len 550)
A3 record.owner_id in ['u0' … 'u199'](200 元素)	REJECT Exceeded maxListElements (64)	true	ok {"owner_id":{"$in":[…]}} (len 1312)

边界对照(20 conjuncts / 8 层嵌套 / 30 元素 $in)三条都是 celEngine ACCEPT + 编译 ok,证明差异确实来自 DEFAULT_LIMITS 而非形状。

端到端复核:真运行期 RLSCompiler 也照下推,且不打 WARN

不止 formula 层。用真 RLSCompiler.compileFilter(单策略,{userId,tenantId} 上下文):

构造	compileFilter 返回	warnings
A1	一条真实下推 filter(len 1110)	(none)
A2	一条真实下推 filter(len 550)	(none)
A3	一条真实下推 filter(len 1312)	(none)

isSupportedRlsExpression 对这三条都答 true,所以 :158 的 WARN 分支不进 —— 超限谓词是静默被编译并下推成安全 SQL 的。

作者侧同样没有拦截:@objectstack/lint 的 validateRlsPredicateEnforceability(:196)在 isSupportedRlsExpression(source) 为 true 时 continue,所以 A1–A3 在 publish 闸上也是绿的。packages/spec/src/security/rls.zod.ts:362 的 using 是裸 z.string().optional(),无长度上界。从 authoring 到运行期没有任何一处会拒绝它们。

A3 尤其不是造出来的形状:一条按 id 白名单写死的 territory / 共享策略就是这个样子,64 个元素并不难越过。

收敛的爆炸半径:界内 21/21 逐字不变

把 getParseEnv() 换成 parseCelToAst 后,对本包既有测试语料(21 条,含全部可下推形状 + 4 条不可下推形状)逐条对比 compileCelToFilter 结果:

corpus=21  identical=21  differing=0

包括正文「不顺手改的理由 2」点名的那条:

SAME   | record.status == 'open' ? record.amount : null
         before: FAIL unsupported: unsupported operator "?:"
         after : FAIL unsupported: unsupported operator "?:"

理由 2 实测不成立 —— rewriteNullableTernary 并没有把三元的拒绝理由从 A 换成 B,?: 在 lowerCondition 里先被拒,dyn(...) 包裹根本没机会影响判定。理由 1(安全接缝上的真行为变更)成立且是全部剩余风险。

因此需要裁决的,正是 hold 评论指名的那一个问题

收敛后,A1–A3 从「编译成 filter 并下推」翻成 parse-error → compileExpression 返回 null → 单策略时 compileFilter 返回 RLS_DENY_FILTER,该对象上的这条策略拒绝全部行。

选项 A — 收敛到 parseCelToAst(超限谓词 fail-closed)

• 一个平台一个「什么能解析」的答案,DEFAULT_LIMITS 恢复成真边界;packages/lint 绕过 @objectstack/formula 直接 parse CEL —— 两个解析入口对「什么能解析」会给出不同答案 #4812 的形状被彻底消灭。
• 界内零回归(21/21 实测)。
• 有一个实打实的缓和面:收敛后 isSupportedRlsExpression 同步变 false,于是 rls-compiler.ts:158 既有的 WARN 会打出来,lint 也会在 publish 时报错 —— 从「静默下推」变成「响亮拒绝 + 作者侧可自纠」。
• 代价:若线上已存在超限 RLS 策略,升级当天该对象从可读变为全拒。这是 fail-closed 方向的破坏性变更,需要 major/迁移说明与一次线上普查。

选项 B — 明确裁定「下推面按纯语法解析另算」,写进文件头

• 零行为变更,零迁移风险。
• 代价:DEFAULT_LIMITS 在这一面永久不适用,谓词规模无上界 —— 一条 10000 元素的 $in 会在该对象每一次查询上下推成 10000 项 SQL IN,这是资源面而非越权面的风险;且「两个入口对同一条源码给不同答案」这个 packages/lint 绕过 @objectstack/formula 直接 parse CEL —— 两个解析入口对「什么能解析」会给出不同答案 #4812 要消灭的形状被正式承认为设计。

倾向 A,但这是维护者的裁决,不是我的。 理由:三轴分歧的产物是安全 SQL,而 declared(DEFAULT_LIMITS 自称是平台边界)与 enforced(下推面不读它)不一致正是 Prime Directive #10 的形状;A 把错误从静默变响亮,方向上与「让 AI 写的 metadata 难以出错」一致;界内零回归也已实测。但 A 会让既有部署的策略从「有效」翻成「全拒」,这个后果只有维护者能承担 —— 若选 A,建议同时确认是否需要一个过渡期(先只打 WARN 不翻 fail-closed)来做线上普查。

范围外发现

测量途中发现 rls.zod.ts 的 check @example status IN ('draft', 'pending') 实测编译不出来(parse-error → fail-closed 全拒),已按 Prime Directive #10 单独记为 #6641,未在本单内修。

---

Generated by Claude Code

[baozhoutao]

🚩 升级为决策箱(engine-core 席 #6019,会话 session_019Q7oc7ASjh8yxyS3Yz78We)

认领已释放(pm:dispatched → needs-user-decision,assignee 清空,零代码落地)。03:58Z hold 的重启条件 ①(测量可达性)已执行完毕,结果触发了本席认领评论里写死的停工分支:可达 ⇒ 不得在 PR 内裁。测量证据见上方评论 5225232530,以下是给维护者的裁决简报。

一、测量结论:三轴全部可达,且无声

在真实 RLSCompiler 上端到端跑通(baseline 0b63b5677),三条超限谓词全部编译出真实下推 filter,零 WARN、零 lint 报错:

轴	谓词形状	celEngine 权威入口	实际下推
maxAstNodes(256)	80 个 record.fN == 'vN' 平衡合取	REJECT	✅ 下推 $and,len 1110
maxDepth(32)	40 个右嵌套合取	REJECT	✅ 下推 $and,len 550
maxListElements(64)	record.owner_id in ['u0'…'u199']	REJECT	✅ 下推 $in,len 1312

边界对照(20/8/30)三家一致接受 ⇒ 分歧确实跟着 DEFAULT_LIMITS 走,不是谓词形状的偶然。第三轴那个 200 元素 id 白名单是普通的属地/共享策略形状,不是构造出来的极端用例。

二、hold 评论继承的两个前提,测量后需更正(重要)

1. 不存在「形状闸在前」这回事。 isSupportedRlsExpression(rls-predicate.ts:59)本身就是 isPushdownableCel(sqlPredicateToCel(x)) —— 即被质疑的那个 limitless env 的薄包装;运行时(plugin-security/src/rls-compiler.ts:221)直接调 compileCelToFilter,:158 只用它事后决定「要不要打 WARN」。没有可供「穿过」的前置闸。授权面也无长度约束(rls.zod.ts:362 的 using 是裸 z.string())。
2. issue 正文自带的三个探针恰好不可达,但原因无关:它们是算术/方法调用形状,lowering 本来就拒(unsupported operator "+" 等)。只测这三个会得出错误的「不可达」结论 —— 这正是 hold 当初没法定案的原因。

另有一条 issue 自陈理由被证伪:rewriteNullableTernary 并不会改变三元被拒的原因(?: 在 lowerCondition 就被拒,前后逐字相同)。剩下的唯一风险就是安全接缝上的行为变更本身。

三、为什么这不是「照 #6130 抄」

#6130 给 lint 收敛时,拒绝的后路是 return [] —— 跳过,把判定交还给拥有它的闸。cel-to-filter 没有这条后路:拒绝 ⇒ parse-error ⇒ RLSCompiler 丢弃策略 ⇒ RLS_DENY_FILTER,该对象整体拒绝。同样的三行改动,后果类别完全不同。

四、请裁决

RLS/共享下推路径上的超限 CEL 谓词,应当 fail-closed(收敛到权威解析入口,DEFAULT_LIMITS 重新生效),还是继续宽松解析并下推(裁定该面「按设计只做语法解析」,把理由写进文件头)?

• A —— 收敛(fail-closed)。 全平台一个「什么能解析」的答案;DEFAULT_LIMITS 重新成为真约束;packages/lint 绕过 @objectstack/formula 直接 parse CEL —— 两个解析入口对「什么能解析」会给出不同答案 #4812 要消灭的形状被消灭。实测在界内零回归(21/21 逐字相同);且收敛后 isSupportedRlsExpression 同步翻假 ⇒ 既有的 WARN 会响、lint 会在发布期拒收,故障从「无声下推」变成「响亮且可自纠的授权期错误」。⚠️ 代价:任何已部署的超限 RLS 策略在升级后从「生效」翻成 RLS_DENY_FILTER —— 那个对象当天从可读变全拒。属破坏性变更,需迁移说明与部署面普查。
• B —— 裁定按设计只做语法解析,写进文件头。零行为变更、零迁移风险。代价:DEFAULT_LIMITS 在这一面永久失效(谓词大小无界 —— 一万元素的 $in 会在每次查询上推出一万项 SQL IN,属资源风险而非授权绕过);且「两个解析入口、对同一源两个答案」这一 packages/lint 绕过 @objectstack/formula 直接 parse CEL —— 两个解析入口对「什么能解析」会给出不同答案 #4812 明确要消灭的形状,变成官方认可的设计。
• A′ —— A 的分阶段版:先让超限谓词响亮可见但仍然生效,普查部署面,下个大版本再翻 fail-closed。

本席建议:A′;若部署面普查干净则直接 A。 理由:DEFAULT_LIMITS 今天声明了一个平台约束,而唯一产出安全 SQL 的那一面不执行它 —— declared ≠ enforced 落在授权路径上;B 是把声明降到最弱消费者的水平(PD #5 排除的绕行方向)。A 把「宽松消费者静默接受」换成「生产者侧响亮拒绝」,正是 contract-first 的方向,而安全接缝是最不该让 AI 生成的元数据错误藏身的地方。唯一让我停手的是:A 是三个选项里唯一会打断运行中部署的,「策略升级后静默翻成全拒」是生产事故,这个代价不该由我替你接受。

⚠️ 在你批复前,任何人不得单独收敛 getParseEnv(包括「顺手」在别的 PR 里)。批 A/A′ 后本席即派实施;批 B 则本单降为一条文件头注释的小改动单。

附带一个次级问题(仅在批 A/A′ 时需要):parseCelToAst 返回 null 丢弃 cel-js 的原文,而 Exceeded maxAstNodes (256) 恰是作者最需要的那句话。建议在 cel-engine 加一个携带原因的姊妹入口(保持单一解析权威),而非退化成通用文案 —— 因为 A 的全部价值就是把无声接受变成可自纠的拒绝,而「canonical parse refused」不可自纠。

dev 另立 #6641(rls.zod.ts 的 check @example status IN ('draft','pending') 编译不过 ⇒ 作者照抄 schema 自带示例即得全拒策略)—— 独立缺陷,已交分诊定级,不在本决策范围。

---

Generated by Claude Code