unbridled-41 opened a new issue, #5468: URL: https://github.com/apache/rocketmq-dashboard/issues/5468
### Studio Version branch: `rocketmq-studio` @ `6a68042f` (the revision verified; the branch is based on it) deployed as: built from source (unit test) ### Runtime Environment Not environment-specific: frontend confirmation behaviour. ### Connected RocketMQ Cluster Not cluster-specific (Ops → System Alerts). ### Describe the Bug The trash button in the system-alerts header calls `clearAcknowledgedAlerts()` straight from `onClick`: no confirmation, no undo, and not styled as a dangerous action. The server really deletes — `AlertService.clearAcknowledged()` → `MybatisPlusAlertRepository.deleteAcknowledgedAlerts()` runs `notificationOutboxMapper.deleteForAcknowledgedAlerts()` and then `alertMapper.delete(... acknowledged = true)`. Every comparable destructive control on these pages asks first (alert-rule delete, audit-log cleanup, session revoke). ### Steps to Reproduce 1. Open Ops → System Alerts with at least one acknowledged alert. 2. Click the trash icon once. ### What Did You Expect to See? A confirmation that states the scope before the purge runs. ### What Did You See Instead? The acknowledged history and its delivery records are deleted immediately. ### Evidence - `web/src/pages/ops/systemAlerts.tsx` (the button), `ops/alert/AlertService.java` + `MybatisPlusAlertRepository.java` (the delete), `web/src/pages/ops/alerts.tsx` (the Popconfirm pattern the neighbours use). - `cd web && npx vitest run src/pages/ops/__tests__/SystemAlertsPage.test.tsx` — the added case fails before the change with `expected "vi.fn()" to not be called at all, but actually been called 1 times` and passes after (`Tests 19 passed`), asserting nothing is deleted before the confirm and that the delete runs after it. ### Impact Irreversible loss of the acknowledged alert history and its delivery records from one stray click. ### Acceptance Criteria - The bulk purge is confirmed, with the scope stated, and a regression test pins that one click does not delete. **Corresponding PR:** #5437 -- 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]
