You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@rocketmq.apache.org by "zjncs (via GitHub)" <gi...@apache.org> on 2026/09/08 03:47:28 UTC

[PR] fix(alert): keep suppressing while a cluster incident only has a REMINDER left [rocketmq-dashboard]

zjncs opened a new pull request, #4119:
URL: https://github.com/apache/rocketmq-dashboard/pull/4119

   ### Motivation
   
   `AlertNotificationSuppressionService.findSuppressingClusterAlert` decides whether a BUSINESS notification is redundant by looking for an active CLUSTER incident in the same scope. It keeps only incidents whose **latest** in-window event is `FIRING`:
   
   ```java
   return latestByIncident.values().stream()
           .filter(candidate -> "FIRING".equalsIgnoreCase(candidate.getTransition()))
           .max(...);
   ```
   
   But `AlertStateMachine.advanceHit` emits `REMINDER` **only while the state stays `FIRING`** — a REMINDER is by definition an active incident — and `NativeAlertEvaluationService.emitsLifecycleEvent` persists REMINDER events for CLUSTER-domain rules too. CLUSTER rules default to a 30-minute `reminderInterval`, the same length as the suppression `CORRELATION_WINDOW` (30m).
   
   Failure scenario: a broker incident fires at t0; at t0+30m the state machine emits a REMINDER; at t0+35m a correlated BUSINESS alert fires. The window `[t0+5m, t0+35m]` now contains **only the REMINDER** (the original FIRING at t0 fell out) → the filter drops it → `Optional.empty()` → the redundant business notification is delivered, exactly the case this class exists to suppress (`/** Finds active cluster incidents that make a business notification redundant. */`). The intended boundary is RESOLVED, as `doesNotSuppressAfterTheSameClusterIncidentHasResolvedTest` shows.
   
   ### Modifications
   
   The filter also accepts `REMINDER` as an active transition (only `RESOLVED` ends an incident).
   
   ### Verification
   
   New test `suppressesWhileTheSameClusterIncidentOnlyReminderRemainsTest` (modeled on the existing resolved-incident test): same fingerprint/scope, the original FIRING outside the window, a `REMINDER` at `now-5m`.
   - Before the fix: fails — `Expecting Optional to contain: but was empty`.
   - After the fix: passes — the REMINDER suppresses the business notification.
   - `mvn -f server/pom.xml test -Dtest='AlertNotificationSuppressionServiceTest,NativeAlertEvaluationServiceTest,AlertStateMachineTest'` → **Tests run: 14, Failures: 0, Errors: 0**.
   


-- 
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: commits-unsubscribe@rocketmq.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [PR] fix(alert): keep suppressing while a cluster incident only has a REMINDER left [rocketmq-dashboard]

Posted by "lizhimins (via GitHub)" <gi...@apache.org>.
lizhimins merged PR #4119:
URL: https://github.com/apache/rocketmq-dashboard/pull/4119


-- 
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: commits-unsubscribe@rocketmq.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org