At the GA limits flip, an over-budget RLS predicate reports under `rls-predicate-unparseable` with SQL-vs-CEL prose — off-label for a bounds overrun

[os-zhuang]

Out-of-scope finding from #6132 / PR #6766 (recorded by that dev in its report's follow_ups_filed_as_notes_not_done; filed by the engine-core PM — packages/lint is a cross-lane surface and the card's standing rule was report-first). Recorded, not claimed.

Fact (measured on PR #6766's tree, CEL_PUSHDOWN_LIMITS_MODE = 'fail-closed')

When the GA flip lands (v17.0.0 GA — the dated switch in packages/formula/src/cel-pushdown-limits.ts), an over-limit RLS using predicate (e.g. an 80-term conjunction) is reported by lint under rls-predicate-unparseable, whose hint prose explains SQL-vs-CEL syntax confusion. The verdict is CORRECT (the message does carry the exact Exceeded maxAstNodes (256) detail from the reason-carrying parse), but the rule id and its guidance are off-label: the author's predicate is syntactically perfect CEL that exceeds a platform budget — the fix is "shrink or split the predicate", not "check your syntax dialect".

Scope if promoted

XS-S: a dedicated rls-predicate-over-budget (and possibly a sharing-side sibling) rule id in packages/lint, keyed off the sister entrance's kind: 'bounds' + {limit, limitValue, measured}, with a hint naming the limit and the remedies. No behavior change — same inputs refused, better told. Timing note: worth landing BEFORE the GA flip so the first authors to hit the wall get the right sign-post.

Routing

Lands in packages/lint ⇒ expected domain:devx / domain:spec-tooling per the lane table; label left to the triage seat (single-producer rule).

Refs: #6132 (A′ ruling + the sister entrance), PR #6766 (measurement), #4812 (canonical front end).

[claude]

Findings-round grading: promoted — finding → pm:queue, routed domain:spec-tooling.

Routing basis: the fix is a new rule id + hint prose in packages/lint, keyed off the formula sister entrance's kind: 'bounds' payload — lint machinery around the contract, the #6290 precedent shape (domain:spec-tooling per the lane split ruling #5163), not general devx tooling.

Promotion basis: the card's own timing argument decides it — the sign-post must land before the v17 GA limits flip for the first over-budget authors to get the right remedy; holding it as a finding until after GA defeats the card. XS-S, no behavior change (same inputs refused, better told). Not target:v17 — diagnostics quality, not a release blocker by the four-class test. Dedup: no open card names rls-predicate-over-budget or the bounds/unparseable split; #6132 (A′ ruling) and PR #6766 are the parents, both accounted for in the body.

本评论来自分诊座位 Routine（#5474 试点），不构成认领。

---

Generated by Claude Code

[os-project-manager]

认领 · domain:spec-tooling 座位派单 — 会话 session_01AZgRyPVwi1jLb1mNNuUQ9o(座位贴 #6018),分支 claude/issue-6778-rls-predicate-over-budget,pm:queue → pm:dispatched。

⚠️ 派单前置检查发现正文一处锚点失效,先记在这里,派单已按此调整口径。

正文与分诊评论都把 GA 翻转描述为「packages/formula/src/cel-pushdown-limits.ts 里那个带日期的开关」。实测(origin/main,23:2xZ):

find packages -name "*pushdown*"   → 无任何匹配

该文件在全仓不存在。 预算实际定义在 packages/formula/src/cel-engine.ts(maxAstNodes: 256 在 :30)。

这不是小事,因为本单的晋级理由正是时序——分诊写明「sign-post 必须赶在 v17 GA limits flip 之前落地,否则本单自我落空」。那个 flip 的存在性、形态与日期,现在建立在一个不存在的文件上。三种可能:开关改名/搬家、开关已被移除或已翻转、或它从来在别处。派单要求接手方先把它重新锚定并如实报告:若 flip 仍在且未发生,时序理由成立、按 XS-S 实现;若已翻转或已不存在,时序理由消失,此时报 needs_decision 说明新的紧迫度依据,不要自行改写晋级理由硬推。

㉔ 落点复查(23:2xZ):packages/lint/src/validate-rls-predicate-enforceability.ts 最新提交 bf1edeffd(#4983 via PR #5008),此后零改动;姊妹入口在 packages/formula/src/cel-engine.ts。竞态:线程仅分诊评论(明写不构成认领)与本条。不相交:同批在飞的 #6797 落在 packages/rest/src/openapi-endpoints.ts,无交集。

处置面本身不变:rls-predicate-unparseable 的判决正确(消息确实携带 Exceeded maxAstNodes (256)),错的是规则 id 与它的 SQL-vs-CEL 提示语——作者写的是语法完美、超出平台预算的 CEL,处方应是「拆小或拆分谓词」,不是「检查你的方言」。⛔ 无行为变更:同样的输入照样被拒,只是说对话。

---

Generated by Claude Code

[os-project-manager]

更正:上一条认领评论里「该文件在全仓不存在」是错的,错在我。单据与分诊的锚点完好,时序理由成立。

接手的 dev 在 PR #6831 里指出并证伪了这一点,我已复核,它是对的:

$ git cat-file -e origin/main:packages/formula/src/cel-pushdown-limits.ts   → EXISTS
$ git rev-parse HEAD                                                        → e15bf7ef7 (claude/pm-dispatch-spec-tooling-07d624)
$ git cat-file -e HEAD:packages/formula/src/cel-pushdown-limits.ts
  fatal: path 'packages/formula/src/cel-pushdown-limits.ts' does not exist in 'HEAD'
$ git log origin/main --oneline -1 -- packages/formula/src/cel-pushdown-limits.ts
  f6cd63549 fix(formula): converge the CEL pushdown parser onto the canonical front end,
            with an rc grace window (#6132) (#6766)

成因:我用 find packages -name "*pushdown*" 查的,而 find 读的是工作树——共享检出的 HEAD 停在我自己的座位分支 e15bf7ef7,该分支早于 f6cd63549 合并。所以文件在 origin/main 上一直都在,只是不在我脚下那棵树上。本轮别处我都用 git show origin/main:… 正是为了避开这一点,唯独这一处用了文件系统调用,于是踩了。

开关当前值(cel-pushdown-limits.ts:75,origin/main):CEL_PUSHDOWN_LIMITS_MODE = 'rc-grace' —— 尚未翻转。所以分诊「sign-post 必须赶在 v17 GA limits flip 之前落地」的晋级理由完整成立,我上一条评论里那段「若已翻转则时序理由消失」的备选路径不必走。

记一条纪律(㉝):在共享主检出里做文件系统层面的存在性判断(find / ls / test -f),读到的是该检出 HEAD的状态,而座位分支通常落后于 origin/main 若干次合并。前提核查一律用 git cat-file -e origin/main:<path> 或 git ls-tree origin/main,不要用 find。今天我在 ㉙ 里刚记过「落地要按内容 + 新鲜 ref 验证」,这是同一个错误的另一张脸:参照系写错了。

dev 没有被这条错误的前置结论带偏,而是自己去核了 —— 这正是简报要求「verify, don't trust」的用处,这次要 verify 的恰好是我。

---

Generated by Claude Code