feat: add raw CEL mode to routing rule builder with inline error display and round-trip edit support - #5289
Merged
Pratham-Mishra04 merged 1 commit intoJul 17, 2026
Conversation
Contributor
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 52 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (7)
📝 WalkthroughWalkthroughRouting rules now support visual-builder and raw-CEL condition modes, including mode switching, CEL validation errors, CEL expression persistence, condition display updates, and end-to-end coverage for valid and malformed expressions. ChangesRouting Rule CEL Editing
Estimated code review effort: 4 (Complex) | ~45 minutes Suggested reviewers: Sequence Diagram(s)sequenceDiagram
participant User
participant RoutingRuleSheet
participant CELRuleBuilder
participant RoutingRuleAPI
User->>CELRuleBuilder: Select CEL mode and enter expression
CELRuleBuilder->>RoutingRuleSheet: Report mode and CEL text
User->>RoutingRuleSheet: Submit rule
RoutingRuleSheet->>RoutingRuleAPI: Save CEL expression
RoutingRuleAPI-->>RoutingRuleSheet: Return success or compile error
RoutingRuleSheet-->>User: Close sheet or show inline error
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
This was referenced Jul 16, 2026
Contributor
Author
18 tasks
impoiler
changed the title
impoiler
force-pushed
the
07-16-feat_routing_rules_cel_expression_validation_front-end
branch
from
July 16, 2026 08:38
061b3d2 to
206069d
Compare
impoiler
force-pushed
the
07-16-feat_routing_rules_cel_expression_validation_backend
branch
from
July 16, 2026 08:38
11b071c to
0698f7b
Compare
impoiler
marked this pull request as ready for review
July 16, 2026 08:40
Contributor
Confidence Score: 5/5No additional blocking issue qualifies for this follow-up review.
Important Files Changed
Reviews (2): Last reviewed commit: "feat: routing Rules CEL expression valid..." | Re-trigger Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@ui/components/ui/custom/celBuilder/celRuleBuilder.tsx`:
- Around line 298-312: Update the CEL textarea and conditional error message in
the mode === "cel" branch: assign the error paragraph a stable unique ID,
reference it from Textarea via aria-describedby, and add role="alert" to
announce server-side errors. Preserve the existing conditional rendering and
celError styling.
- Around line 165-189: The mode-switch handlers must no-op when their target
mode is already active. Update switchToCel and requestSwitchToBuilder (or the
button handlers invoking them) to check the current mode before changing text,
state, or opening the discard confirmation, while preserving the existing
conversion and confirmation behavior for actual mode changes.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: 9e05f1b4-e876-4e3d-9414-f7351fe41838
📒 Files selected for processing (7)
tests/e2e/features/routing-rules/pages/routing-rules.page.tstests/e2e/features/routing-rules/routing-rules.spec.tsui/app/workspace/routing-rules/components/celBuilder/celRuleBuilder.tsxui/app/workspace/routing-rules/views/routingRuleInfoSheet.tsxui/app/workspace/routing-rules/views/routingRuleSheet.tsxui/components/ui/custom/celBuilder/celRuleBuilder.tsxui/components/ui/custom/celBuilder/index.ts
18 tasks
Collaborator
Merge activity
|
Pratham-Mishra04
changed the base branch from
07-16-feat_routing_rules_cel_expression_validation_backend
to
graphite-base/5289
July 17, 2026 11:09
Pratham-Mishra04
dismissed
coderabbitai[bot]’s stale review
July 17, 2026 11:11
The base branch was changed.
Pratham-Mishra04
force-pushed
the
07-16-feat_routing_rules_cel_expression_validation_front-end
branch
from
July 17, 2026 11:12
206069d to
db30aea
Compare
Pratham-Mishra04
deleted the
07-16-feat_routing_rules_cel_expression_validation_front-end
branch
July 17, 2026 11:14
akshaydeo
pushed a commit
that referenced
this pull request
Jul 17, 2026
…lay and round-trip edit support (#5289) ## Summary Routing rules authored outside the visual builder (e.g. via the API) carry a raw CEL expression but no `query` object. Previously, opening such a rule in the edit sheet would silently discard the CEL expression because the builder initialised in visual mode with an empty query. This PR adds a raw CEL editing mode to the conditions editor so those rules can be viewed, edited, and saved without data loss. ## Changes - Added a **Builder | CEL toggle** to the `CELRuleBuilder` component. When in CEL mode, the expression is hand-editable in a textarea and drives `onChange` directly, bypassing the visual query builder. - Rules with a `cel_expression` but no visual `query` now open in CEL mode automatically (`initialConditionMode` helper in `routingRuleSheet.tsx`). - Switching from CEL back to Builder shows a confirmation dialog warning that the hand-written CEL will be discarded (no CEL→query parser exists), and seeds the CEL textarea from the builder's current output when switching the other direction. - Server-side CEL compile errors (400 responses) are now surfaced inline beneath the CEL textarea (`celError` prop) rather than as a toast, keeping the error contextual to the field that caused it. - Builder-only validations (regex patterns, rate limit/budget rules) are skipped when in CEL mode, since those inspect the visual query which does not exist in that mode. - The info sheet (`routingRuleInfoSheet.tsx`) now distinguishes between "Matches all requests" and "Defined as a CEL expression below" when a rule has a CEL expression but no visual query. - E2E tests cover: creating a rule in raw CEL mode and verifying it round-trips through edit with the expression intact, and rejecting a malformed CEL expression with an inline error while keeping the sheet open and not creating the rule. - New page-object helpers: `openEditSheet`, `switchToCelMode`, `fillCelExpression`, `getCelTextareaValue`, `isCelMode`, `celTextarea`, `celError`. ## Type of change - [ ] Bug fix - [x] Feature - [ ] Refactor - [ ] Documentation - [ ] Chore/CI ## Affected areas - [ ] Core (Go) - [ ] Transports (HTTP) - [ ] Providers/Integrations - [ ] Plugins - [x] UI (React) - [ ] Docs ## How to test ```sh cd ui pnpm i pnpm build # E2E pnpm exec playwright test tests/e2e/features/routing-rules/routing-rules.spec.ts ``` 1. Create a routing rule via the API with a raw CEL expression and no `query` field. 2. Open the rule in the UI — it should open in CEL mode with the expression visible in the textarea. 3. Save without changes — the expression should be preserved after reopening. 4. Enter a malformed CEL expression (e.g. unbalanced parenthesis) and save — the sheet should stay open and show an inline error beneath the textarea. 5. Switch from CEL mode to Builder mode with a non-empty expression — a confirmation dialog should appear warning that the CEL will be discarded.  ## Breaking changes - [ ] Yes - [x] No ## Related issues ## Security considerations No new auth, secrets, or PII surface area introduced. CEL expressions are validated server-side before persistence. ## Checklist - [x] I read `docs/contributing/README.md` and followed the guidelines - [x] I added/updated tests where appropriate - [ ] I updated documentation where needed - [x] I verified builds succeed (Go and UI) - [ ] I verified the CI pipeline passes locally if applicable
akshaydeo
pushed a commit
that referenced
this pull request
Jul 18, 2026
…lay and round-trip edit support (#5289) ## Summary Routing rules authored outside the visual builder (e.g. via the API) carry a raw CEL expression but no `query` object. Previously, opening such a rule in the edit sheet would silently discard the CEL expression because the builder initialised in visual mode with an empty query. This PR adds a raw CEL editing mode to the conditions editor so those rules can be viewed, edited, and saved without data loss. ## Changes - Added a **Builder | CEL toggle** to the `CELRuleBuilder` component. When in CEL mode, the expression is hand-editable in a textarea and drives `onChange` directly, bypassing the visual query builder. - Rules with a `cel_expression` but no visual `query` now open in CEL mode automatically (`initialConditionMode` helper in `routingRuleSheet.tsx`). - Switching from CEL back to Builder shows a confirmation dialog warning that the hand-written CEL will be discarded (no CEL→query parser exists), and seeds the CEL textarea from the builder's current output when switching the other direction. - Server-side CEL compile errors (400 responses) are now surfaced inline beneath the CEL textarea (`celError` prop) rather than as a toast, keeping the error contextual to the field that caused it. - Builder-only validations (regex patterns, rate limit/budget rules) are skipped when in CEL mode, since those inspect the visual query which does not exist in that mode. - The info sheet (`routingRuleInfoSheet.tsx`) now distinguishes between "Matches all requests" and "Defined as a CEL expression below" when a rule has a CEL expression but no visual query. - E2E tests cover: creating a rule in raw CEL mode and verifying it round-trips through edit with the expression intact, and rejecting a malformed CEL expression with an inline error while keeping the sheet open and not creating the rule. - New page-object helpers: `openEditSheet`, `switchToCelMode`, `fillCelExpression`, `getCelTextareaValue`, `isCelMode`, `celTextarea`, `celError`. ## Type of change - [ ] Bug fix - [x] Feature - [ ] Refactor - [ ] Documentation - [ ] Chore/CI ## Affected areas - [ ] Core (Go) - [ ] Transports (HTTP) - [ ] Providers/Integrations - [ ] Plugins - [x] UI (React) - [ ] Docs ## How to test ```sh cd ui pnpm i pnpm build # E2E pnpm exec playwright test tests/e2e/features/routing-rules/routing-rules.spec.ts ``` 1. Create a routing rule via the API with a raw CEL expression and no `query` field. 2. Open the rule in the UI — it should open in CEL mode with the expression visible in the textarea. 3. Save without changes — the expression should be preserved after reopening. 4. Enter a malformed CEL expression (e.g. unbalanced parenthesis) and save — the sheet should stay open and show an inline error beneath the textarea. 5. Switch from CEL mode to Builder mode with a non-empty expression — a confirmation dialog should appear warning that the CEL will be discarded.  ## Breaking changes - [ ] Yes - [x] No ## Related issues ## Security considerations No new auth, secrets, or PII surface area introduced. CEL expressions are validated server-side before persistence. ## Checklist - [x] I read `docs/contributing/README.md` and followed the guidelines - [x] I added/updated tests where appropriate - [ ] I updated documentation where needed - [x] I verified builds succeed (Go and UI) - [ ] I verified the CI pipeline passes locally if applicable
18 tasks
akhsaul
pushed a commit
to akhsaul/bifrost
that referenced
this pull request
Aug 27, 2026
…lay and round-trip edit support (maximhq#5289) ## Summary Routing rules authored outside the visual builder (e.g. via the API) carry a raw CEL expression but no `query` object. Previously, opening such a rule in the edit sheet would silently discard the CEL expression because the builder initialised in visual mode with an empty query. This PR adds a raw CEL editing mode to the conditions editor so those rules can be viewed, edited, and saved without data loss. ## Changes - Added a **Builder | CEL toggle** to the `CELRuleBuilder` component. When in CEL mode, the expression is hand-editable in a textarea and drives `onChange` directly, bypassing the visual query builder. - Rules with a `cel_expression` but no visual `query` now open in CEL mode automatically (`initialConditionMode` helper in `routingRuleSheet.tsx`). - Switching from CEL back to Builder shows a confirmation dialog warning that the hand-written CEL will be discarded (no CEL→query parser exists), and seeds the CEL textarea from the builder's current output when switching the other direction. - Server-side CEL compile errors (400 responses) are now surfaced inline beneath the CEL textarea (`celError` prop) rather than as a toast, keeping the error contextual to the field that caused it. - Builder-only validations (regex patterns, rate limit/budget rules) are skipped when in CEL mode, since those inspect the visual query which does not exist in that mode. - The info sheet (`routingRuleInfoSheet.tsx`) now distinguishes between "Matches all requests" and "Defined as a CEL expression below" when a rule has a CEL expression but no visual query. - E2E tests cover: creating a rule in raw CEL mode and verifying it round-trips through edit with the expression intact, and rejecting a malformed CEL expression with an inline error while keeping the sheet open and not creating the rule. - New page-object helpers: `openEditSheet`, `switchToCelMode`, `fillCelExpression`, `getCelTextareaValue`, `isCelMode`, `celTextarea`, `celError`. ## Type of change - [ ] Bug fix - [x] Feature - [ ] Refactor - [ ] Documentation - [ ] Chore/CI ## Affected areas - [ ] Core (Go) - [ ] Transports (HTTP) - [ ] Providers/Integrations - [ ] Plugins - [x] UI (React) - [ ] Docs ## How to test ```sh cd ui pnpm i pnpm build # E2E pnpm exec playwright test tests/e2e/features/routing-rules/routing-rules.spec.ts ``` 1. Create a routing rule via the API with a raw CEL expression and no `query` field. 2. Open the rule in the UI — it should open in CEL mode with the expression visible in the textarea. 3. Save without changes — the expression should be preserved after reopening. 4. Enter a malformed CEL expression (e.g. unbalanced parenthesis) and save — the sheet should stay open and show an inline error beneath the textarea. 5. Switch from CEL mode to Builder mode with a non-empty expression — a confirmation dialog should appear warning that the CEL will be discarded.  ## Breaking changes - [ ] Yes - [x] No ## Related issues ## Security considerations No new auth, secrets, or PII surface area introduced. CEL expressions are validated server-side before persistence. ## Checklist - [x] I read `docs/contributing/README.md` and followed the guidelines - [x] I added/updated tests where appropriate - [ ] I updated documentation where needed - [x] I verified builds succeed (Go and UI) - [ ] I verified the CI pipeline passes locally if applicable
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Routing rules authored outside the visual builder (e.g. via the API) carry a raw CEL expression but no
queryobject. Previously, opening such a rule in the edit sheet would silently discard the CEL expression because the builder initialised in visual mode with an empty query. This PR adds a raw CEL editing mode to the conditions editor so those rules can be viewed, edited, and saved without data loss.Changes
CELRuleBuildercomponent. When in CEL mode, the expression is hand-editable in a textarea and drivesonChangedirectly, bypassing the visual query builder.cel_expressionbut no visualquerynow open in CEL mode automatically (initialConditionModehelper inroutingRuleSheet.tsx).celErrorprop) rather than as a toast, keeping the error contextual to the field that caused it.routingRuleInfoSheet.tsx) now distinguishes between "Matches all requests" and "Defined as a CEL expression below" when a rule has a CEL expression but no visual query.openEditSheet,switchToCelMode,fillCelExpression,getCelTextareaValue,isCelMode,celTextarea,celError.Type of change
Affected areas
How to test
queryfield.Breaking changes
Related issues
Security considerations
No new auth, secrets, or PII surface area introduced. CEL expressions are validated server-side before persistence.
Checklist
docs/contributing/README.mdand followed the guidelines