feat(uptime): Display assertion compilation errors in form #106922
Conversation
Add error handling for assertion compilation/serialization errors from
the uptime-checker validator. When the API returns an error like
`{"assertion": {"error": "compilation_error", "details": "..."}}`,
the form now properly extracts and displays the error message on
the Assertions field in the Verification section.
Add descriptive titles to assertion validation errors based on error type: - "Compilation Error" for invalid JSON path syntax - "Serialization Error" for malformed assertion structure - "Validation Error" as fallback Also adds test coverage for serialization errors.
github-actions
bot
added
the
Scope: Frontend
- Extract assertion error mapping to shared utility (assertionFormErrors.tsx)
- Handle both API response formats:
- Direct: {"assertion": {"error": "...", "details": "..."}}
- Nested: {"dataSources": {"assertion": {"error": "...", "details": "..."}}}
- Add mapAssertionFormErrors to detector create/edit forms
- Add comprehensive unit tests for error mapping
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the Cursor dashboard.
| result.assertion = formatAssertionError(result.dataSources.assertion); | ||
| // Clean up the nested structure | ||
| delete result.dataSources; | ||
| } |
There was a problem hiding this comment.
Deleting dataSources may lose other error fields
Low Severity
When processing a nested assertion error, delete result.dataSources removes the entire object. If the API response contains other error fields within dataSources (e.g., url or method validation errors alongside the assertion error), those errors would be silently dropped and not displayed to the user. The form sends multiple fields under dataSources (url, method, headers, body, etc.), so if validation errors for these fields are returned nested under dataSources, they would be lost.
| /** | ||
| * Checks if an object is an assertion error with error type and details. | ||
| */ | ||
| function isAssertionError(obj: any): obj is {details: string; error: string} { |
There was a problem hiding this comment.
should this be unknown
| function isAssertionError(obj: any): obj is {details: string; error: string} { | |
| function isAssertionError(obj: unknown): obj is {details: string; error: string} { |
Summary
Display assertion compilation/serialization errors from the uptime-checker validator in uptime monitor forms. When an invalid assertion is submitted (e.g., malformed JSON path syntax), the error is now displayed on the Assertions field in the Verification section with a descriptive title.
Changes
mapAssertionFormErrorsutility to transform assertion errors into form-friendly format{"assertion": {"error": "...", "details": "..."}}(uptime alerts){"dataSources": {"assertion": {"error": "...", "details": "..."}}}(detector forms)/alerts/rules/uptime/)/detectors/uptime/new/)/detectors/uptime/:id/edit/)Manual Test Plan
Test compilation error in Uptime Alert form:
$[invalid)Test compilation error in Detector form:
Test serialization error:
Fixes NEW-700