fix(formula): report an unnameable bound as limit: null, not as a guessed key (#6132)

`parseCelToAstWithReason`'s "cel-js raised a limit fault whose key this package
cannot read" branch filled the overrun with `maxAstNodes` while its own comment
said a guessed name is the thing to avoid. It is unreachable on cel-js 8.0.0 —
`Parser#limitExceeded` always phrases it `Exceeded <key> (<n>)` — but a guessed
key is worse than none: the author goes and shortens the wrong axis. The branch
now reports `{ limit: null, limitValue: null }`, which the types carry, and
hands back no unbounded AST, so the pushdown path fails closed on it in either
position of the switch rather than compiling something it cannot describe.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Bx3H8DJhBsmgDoMp8Tz87T

Author: claude

packages/formula/src/cel-engine.ts

@@ -286,10 +286,15 @@ const CEL_LIMIT_KEYS = Object.keys(DEFAULT_LIMITS) as readonly CelLimitKey[];
 
 /** How far past a {@link DEFAULT_LIMITS} bound a source actually reaches. */
 export interface CelBoundsOverrun {
-  /** WHICH bound was exceeded — `maxAstNodes` / `maxDepth` / `maxListElements` / … */
-  limit: CelLimitKey;
+  /**
+   * WHICH bound was exceeded — `maxAstNodes` / `maxDepth` / `maxListElements` / …
+   * `null` only if cel-js reports a limit fault this package cannot name (see
+   * {@link limitKeyOf}); a guessed key would send the author to shorten the
+   * wrong axis, so the honest answer is "we know it was a bound, not which".
+   */
+  limit: CelLimitKey | null;
   /** The platform's value for that bound, i.e. what the source had to stay under. */
-  limitValue: number;
+  limitValue: number | null;
   /**
    * What the source itself measures on that axis: the smallest value of
    * `limits[limit]` under which it parses, every OTHER bound lifted, so the
@@ -472,20 +477,24 @@ export function parseCelToAstWithReason(
     if (classifyCelFault(err) !== 'bounds') return { ok: false, kind: 'parse', message };
     const parseErr = err as ParseError;
     const limit = limitKeyOf(parseErr);
-    const limitValue = limit ? DEFAULT_LIMITS[limit] : Number.NaN;
     const summary = parseErr.summary ?? message.split('\n')[0];
     if (!limit) {
-      // A bounds fault we cannot name. Report it as bounds (the class is not in
-      // doubt) with no measure — never as a syntax fault, which is the exact
-      // mislabel this entrance exists to stop.
+      // A bounds fault we cannot NAME — unreachable on cel-js 8.0.0, where
+      // `Parser#limitExceeded` always phrases it `Exceeded <key> (<n>)`, but a
+      // rephrasing upstream has to degrade honestly. Still reported as `bounds`
+      // (the class is not in doubt) and never as a syntax fault, which is the
+      // exact mislabel this entrance exists to stop — but with `limit: null`
+      // rather than a guessed key, and with no AST to admit, so the pushdown
+      // path fails closed on it in either position of the switch.
       return {
         ok: false,
         kind: 'bounds',
         message,
-        overrun: { limit: 'maxAstNodes', limitValue: DEFAULT_LIMITS.maxAstNodes, measured: null, summary },
+        overrun: { limit: null, limitValue: null, measured: null, summary },
         unboundedAst: null,
       };
     }
+    const limitValue = DEFAULT_LIMITS[limit];
     let unboundedAst: CelAstNode | null = null;
     let measured: number | null = null;
     if (opts.admitOverLimit) {

packages/formula/src/cel-to-filter.ts

@@ -172,13 +172,19 @@ function warnOverLimitPushdown(source: string, overrun: CelBoundsOverrun): void
   if (warnedOverLimit.has(source)) return;
   if (warnedOverLimit.size >= WARNED_OVER_LIMIT_MAX) warnedOverLimit.clear();
   warnedOverLimit.add(source);
-  const measure = overrun.measured === null
-    ? `over ${overrun.limitValue * CEL_BOUNDS_MEASURE_CAP_FACTOR} (measurement capped)`
-    : String(overrun.measured);
+  // `limit` / `limitValue` are non-null on this path by construction: a bounds
+  // fault whose key could not be named yields no unbounded AST, so it never
+  // reaches the grace window. The fallbacks keep the sentence readable rather
+  // than printing `null` if that ever stops being true.
+  const measure = overrun.measured !== null
+    ? String(overrun.measured)
+    : overrun.limitValue === null
+      ? 'over the measurement cap'
+      : `over ${overrun.limitValue * CEL_BOUNDS_MEASURE_CAP_FACTOR} (measurement capped)`;
   const shown = source.length > 200 ? `${source.slice(0, 197)}...` : source;
   hostConsole()?.warn?.(
-    `[cel-to-filter] pushdown predicate exceeds the platform CEL bound ${overrun.limit} ` +
-      `(limit ${overrun.limitValue}, this predicate measures ${measure}): ${overrun.summary}. ` +
+    `[cel-to-filter] pushdown predicate exceeds the platform CEL bound ${overrun.limit ?? '(unnamed)'} ` +
+      `(limit ${overrun.limitValue ?? 'unknown'}, this predicate measures ${measure}): ${overrun.summary}. ` +
       `It still compiles during 17.0.0-rc.x; at v17 GA it will be REFUSED (parse-error) and the ` +
       `RLS/sharing pushdown path will fail closed (RLS_DENY_FILTER). Split it or move the logic ` +
       `to a hook/action body before upgrading. Predicate: ${shown}`,