unbridled-41 opened a new issue, #4885: URL: https://github.com/apache/rocketmq-dashboard/issues/4885
### Before Creating the Bug Report - [x] I have searched the [open issues](https://github.com/apache/rocketmq-dashboard/issues) and found no similar issue. ### Studio Version - branch: `rocketmq-studio` (dev trunk), base commit `4c697f07` - The defect exists in the current code: `server/src/main/java/org/apache/rocketmq/studio/ops/alert/MybatisPlusAlertRepository.java` (`readLabels`, ~line 402) and `MybatisPlusAlertStateRepository.java` (`readLabels`, ~line 202). ### Describe the Bug `readLabels` throws `IllegalStateException` when a `rmq_system_alert` row's `labels_json` column does not parse as JSON. `findAlertsPage` maps every row of the page through `toAlertVO` → `readLabels`, so a single corrupt row escalates to a query-level failure: - `GET /api/system-alerts/page` (and the legacy `GET /api/system-alerts`) fails with a 500 for as long as the corrupt row is in the result set. The list endpoint stays broken until the row is repaired by hand. - `AlertNotificationSuppressionService.findSuppressingClusterAlert` pages the same repository query inside every BUSINESS-domain FIRING/REMINDER evaluation. `NativeAlertProcessor` catches the resulting `RuntimeException` per rule and only counts/logs it, so the native alerting pipeline keeps running but no evaluation of affected rules succeeds and no notifications go out. `labels` is an optional TEXT column with no writer-side guarantee of valid JSON (external/manual edits possible), so a row-level decode failure is not a condition the read path can treat as fatal. The codebase's own convention for unreadable persisted payloads is skip/degrade — `AiConversationService.decode` documents "An unreadable payload is skipped rather than fatal". ### Steps to Reproduce 1. Set one `rmq_system_alert.labels_json` value to a non-JSON string (e.g. `{not-json`). 2. Call `GET /api/system-alerts/page` → 500, caused by `IllegalStateException: Unable to read alert labels`. 3. With any business alert rule enabled, observe the collector log: each evaluation of rules that reach the suppression candidate query fails with the same exception (`Native alert evaluation failed ... cause=IllegalStateException`), and no notifications are emitted. Steps 2 and 3 are also pinned by the regression test `MybatisPlusAlertRepositoryTest#pageAlertsShouldTolerateACorruptLabelsRowInsteadOfFailingTheQuery`, which failed with `IllegalStateException: Unable to read alert labels` before the fix. ### What Did You Expect to See? The system-alert list renders every row; a row whose `labels_json` cannot be parsed renders with empty labels. Alert evaluations continue: one corrupt row must not cost the pipeline its read of cluster incidents. ### What Did You See Instead? A 500 on the list endpoint and per-evaluation failures for every business rule, until the row is fixed manually in the database. ### Additional Context Fixed by #4871, which degrades an unreadable `labels_json` to an empty map in both alert repositories (same contract for `MybatisPlusAlertRepository` and `MybatisPlusAlertStateRepository`). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
