iloveeyjafjalla opened a new issue, #7020:
URL: https://github.com/apache/rocketmq-dashboard/issues/7020
## Summary
「清除已确认」(Clear acknowledged) removes the acknowledged system alerts and their
pending deliveries but leaves the **ACKED runtime state** behind. That state
can then never be resolved and never fire again:
1. A rule fires → state `FIRING`, event E1, delivery queued.
2. Operator acknowledges E1 → state `ACKED`.
3. Operator clicks 清除已确认 → E1 and its delivery are deleted; the state row
stays `ACKED`.
4. The group/broker disappears (or the metric stops) → reconciliation should
emit RESOLVED, but it cannot:
- `MybatisPlusAlertStateRepository.findActive` selects `FIRING`/`ACKED`
states and then **drops** any whose latest alert row is gone (`toActiveState` →
`Optional.empty()`), so `reconcileMissingActiveStates` never sees the episode.
5. The group returns with the same breach → the stale `ACKED` state advances
to `NONE` → **no FIRING event, no notification**; only the rules table still
shows `ACKED`.
## Why
- `AlertService.clearAcknowledged`
(`server/src/main/java/org/apache/rocketmq/studio/ops/alert/AlertService.java:615-624`)
only calls `alertRepository.deleteAcknowledgedAlerts()`.
- The state table keeps just `(rule_id, fingerprint)` (`rmq_alert_state`),
so `MybatisPlusAlertStateRepository.findActive`/`toActiveState` (`:114-180`)
reconstructs the incident's `instanceId`/labels from the latest
`rmq_system_alert` row — the very row the clear deletes.
- Reconciliation iterates only `findActive()`
(`NativeAlertProcessor.reconcileMissingActiveStates`), so a state dropped there
is never advanced.
## Impact
After one acknowledge+clear, an incident is frozen: no recovery event or
notification when the resource disappears, and a recurrence on the same series
is silently swallowed — the rules table and the system-alert feed disagree
forever. Cluster-scoped notification suppression for the same instance also
loses its event.
## Reproduction
`AlertServiceTest` →
`clearAcknowledgedShouldDropTheStatesBehindTheClearedEventsTest` (the clear
must drop those states before deleting the events that name them):
```
Wanted but not invoked: alertStateRepository.deleteForAcknowledgedAlerts()
```
## Expected
Clearing the acknowledged history also clears the episode state it was the
only evidence for; a series that is still breaching starts a fresh incident
(new event, new notification) instead of being muted by a state nobody can
resolve.
--
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]
