tju-yxq opened a new issue, #6160:
URL: https://github.com/apache/rocketmq-dashboard/issues/6160
> Resubmission of #5243 — the original report was closed by the repo's 7-day
stale bot for inactivity, not because it was fixed or rejected; the problem is
still reproducible on the current `rocketmq-studio` head. An updated PR
carrying the fix is being filed against this report.
## Problem
Acknowledging the System Alerts feed is a row-by-row action. When a fleet
incident floods the feed — one rule misfiring across many brokers, or a
maintenance window that fired a burst of reminders — operators clear the
backlog by clicking **确认** on each alert, twenty per page, across however many
pages the filters match. The bulk actions that do exist are adjacent but not
this: **清除已确认** removes already-acknowledged alerts from view, and the
deliveries feed has a bulk retry, but nothing acknowledges the unacknowledged
set.
Worse than the click count: the per-row acknowledge is the only path that
ACKs the active alert state (which stops reminders, per #4242), so there is no
way to stop a reminder storm in one action — every firing episode has to be
acknowledged individually or the reminders keep coming.
## Current behavior and reproduction
1. Open **Ops > System Alerts** after an incident that produced, say, 80
unacknowledged alerts matching the `error` level filter.
2. The header toolbar offers **导出 CSV**, **维护窗口**, **清除已确认** — no bulk
acknowledge.
3. Acknowledging means clicking **确认** on each row (20 per page, 4 pages),
each click also ACK-ing that alert's active state one at a time.
`web/src/pages/ops/systemAlerts.tsx`: `handleAck` acknowledges one id;
`SystemAlertController` exposes only `POST /acknowledge` (single id) and `POST
/clear-acknowledged` (delete of acked rows).
## Proposed behavior
- A `POST /api/system-alerts/acknowledge-all` endpoint that accepts the same
filter surface as `GET /api/system-alerts/page` (level, domain, instanceId,
transition, labelKey/labelValue, from/to, notificationSuppressed) and
acknowledges every **unacknowledged** alert matching those filters — across
pages, not just the loaded one.
- Each acknowledged FIRING/REMINDER event ACKs its active alert state with
the same rule as the single-row path, so reminders stop for the whole batch.
- The batch is bounded (reject with 400 beyond 10,000 alerts so the request
cannot run away) and runs in one transaction with a single audit record naming
the count and the active filters.
- The page gains a **全部确认** toolbar button (disabled when the loaded page
has nothing unacknowledged) guarded by a confirmation dialog that states the
cross-pages semantics; on success it shows the acknowledged count and refreshes
to page 1.
## Acceptance criteria
- [ ] The endpoint acknowledges every matching unacknowledged alert and
returns `{acknowledged: n}`; already-acknowledged alerts matching the filters
are left untouched and not counted.
- [ ] A FIRING/REMINDER event in the batch ACKs its active alert state at
its own timestamp (same contract as the single-row acknowledge, per #4242);
RESOLVED events do not.
- [ ] Result sets beyond 10,000 alerts are rejected with 400 naming the
limit instead of partially acknowledging.
- [ ] One audit record covers the batch with the acknowledged count and the
filter set.
- [ ] The button is disabled when the loaded page has no unacknowledged
alerts, requires confirmation, and the confirmation copy states that it applies
across pages.
- [ ] Regression coverage: the service test pins the per-alert acknowledge +
state-ACK behavior and the cap; the controller test pins the filter
pass-through; the page test pins the confirm-gated call and the disabled state.
## Importance
Must-have for incident cleanup. After a burst, clicking 80 individual
acknowledges (or leaving reminders firing because nobody clicks at all) is
exactly the kind of toil bulk actions exist for; every neighboring inventory
(deliveries retry, silence windows, audit cleanup) already has its bulk form.
The current workaround — acknowledging row by row — actively discourages
stopping reminder storms, which is the time-sensitive part.
## Duplicate check
Searched open and closed issues/PRs for `"acknowledge all"`, `"bulk
acknowledge"`, `批量确认`, and `acknowledge alerts`. The closest matches are #4243
(fixed: acknowledging a reminder event ACKs the active state — the single-row
rule this builds on), #2004/#2014 (fixed: clear/resurrect races), and #5014
(open, external: exposing alerts to MCP diagnostics — a different surface). No
issue or PR proposes a bulk acknowledgement.
--
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]
