Skip to content

CEL blocking errors are dropped on the floor in ConditionBuilder and ConditionalFormattingEditor too — same ungated-Save family as #4306 #4527

Description

@yinlianghui

Summary

While measuring #4306 (field inspector Save not gated on CEL errors) I found the same
wiring gap in two more CelPredicateField hosts, reaching four further inspectors.

CelPredicateField reports its lint verdict upward through onLintChange(issues)
(packages/app-shell/src/views/metadata-admin/CelPredicateField.tsx line 97, fired at
line 160). Only PermissionAdvancedFacets passes it. Every other mount site discards
the verdict, so a blocking parse fault is rendered inline and nothing acts on it.

Measured mount sites that pass no onLintChange

Zero hits for onLintChange or onCelErrorsChange in either file, confirmed against a
known-present neighbour (PermissionAdvancedFacets.tsx lines 364 / 380), so this is an
absence rather than a search miss.

Why this is filed separately and blocked

The fix is not local to these components. Like #4306, the Save button these editors would
have to gate belongs to a hostStudioDesignSurface.tsx or ResourceEditPage.tsx
reached only through the MetadataInspectorProps registry contract, which today carries
no error channel, and there is no React context anywhere in metadata-admin or
studio-design to carry one instead (zero createContext hits in both trees).

So whichever channel #4306 settles on decides this one too. If that channel is named for
CEL specifically it will need renaming to cover these sites; if it is named for blocking
issues generally, wiring these four inspectors is mostly mechanical.

Blocked-by: #4306

Not reproduced in a browser — this is static evidence from the same sweep that measured
#4306, filed so it is not lost.


Generated by Claude Code

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions