unbridled-41 opened a new issue, #4886: URL: https://github.com/apache/rocketmq-dashboard/issues/4886
### 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: `AlertService.findRelatedAlerts` (`server/src/main/java/org/apache/rocketmq/studio/ops/alert/AlertService.java`, ~line 558-565), exposed at `GET /api/system-alerts/{id}/related` (`SystemAlertController.java:70`). ### Describe the Bug `findRelatedAlerts` queries the ±30-minute correlation window with `transition="FIRING"` and a single page of 100 rows. Two observable consequences: 1. A cluster incident that fired more than 30 minutes ago and is still active only through its in-window REMINDER events is invisible to the related-alerts panel. `AlertNotificationSuppressionService.findSuppressingClusterAlert` deliberately treats that same incident as active ("REMINDER is emitted only while the state stays FIRING, so an incident whose latest in-window event is a REMINDER is still active") and passes `transition=null` with in-memory `FIRING || REMINDER` filtering — the two implementations of the same correlation semantic disagree. 2. When more than 100 candidate events exist in the window, everything beyond the first page was silently dropped; the suppression counterpart pages until `total` is reached. ### Steps to Reproduce 1. Let a cluster alert fire, then keep it firing past 30 minutes so the only in-window events are REMINDER rows (this is the normal steady state of an active incident under the reminder interval). 2. Trigger a business alert on the same instance and scope within the window. 3. Open `GET /api/system-alerts/{business-alert-id}/related` → the still-active cluster incident is missing from the response. 4. (Coverage variant) With >100 cross-domain events in the window, only the first 100 are ever considered. The behavior is pinned by `AlertServiceTest#relatedAlertsShouldIncludeAnIncidentWhoseInWindowEventIsAReminderTest`, which fails before the fix (the reminder-only incident is absent from the result). ### What Did You Expect to See? The related-alerts panel lists cross-domain incidents that are active in the window — including incidents whose latest in-window event is a REMINDER — and considers all candidates in the window, not only the first page. ### What Did You See Instead? Reminder-only active incidents are omitted (while notification suppression still acts on them), and candidates beyond the first 100 rows are ignored. ### Additional Context Fixed by #4873, which drops the transition constraint from the window query, filters candidates in memory against `FIRING || REMINDER` (mirroring `AlertNotificationSuppressionService`), and pages through the window. -- 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]
