tju-yxq opened a new issue, #5167: URL: https://github.com/apache/rocketmq-dashboard/issues/5167
## Problem During an incident review, the report needs both halves of the alerting story: what fired (the system alert feed, which is exportable) and what was intentionally muted (the maintenance windows). The maintenance-window inventory — which windows existed, for which rules/instances/labels, in which time zone, with what reason and by whom — can only be read from the paginated dialog ten rows at a time. For a compliance or post-incident attachment, the operator has to page through the dialog and transcribe rows by hand. This bites exactly when silences matter most: recurring weekly windows (e.g. a nightly batch job muted every weekday 02:00–03:00 in `Asia/Shanghai`) are the ones auditors ask about, and their recurrence schedule is invisible in any current export. ## Current behavior and reproduction 1. Open **Ops > System Alerts** and click **维护窗口 / Maintenance windows**. 2. The dialog lists the silences the current deployment has created, paginated at 10 rows per page (`web/src/pages/ops/systemAlerts.tsx`, `silencePageSize = 10` around line 176). 3. Each row shows domain, instance scope, the window bounds, labels, and — for recurring windows — the time zone and repeat-until date. 4. The alert feed itself has an **Export CSV** button (around lines 273-307, `exportAlerts`), but inside the maintenance-windows dialog there is no export action of any kind; the only server surface is `GET /api/alert-silences` and `GET /api/alert-silences/page` (`server/src/main/java/org/apache/rocketmq/studio/ops/alert/AlertSilenceController.java`, lines 40-49), which return JSON pages meant for the dialog. Want to attach "every window that was active during the incident, who created it and why" to the incident report → impossible without manual transcription across pages. ## Proposed behavior - A `GET /api/alert-silences/export` endpoint streams the full maintenance-window inventory as CSV (`text/csv;charset=UTF-8`, `Content-Disposition: attachment`), following the pattern of the deliveries export (`GET /api/system-alerts/deliveries/export`). - Columns cover the complete audit picture: silence id, domain, rule id, instance id, label matchers, window start/end (UTC, column names labelled `startsAtUtc`/`endsAtUtc` like the audit export's zone-labelled columns), recurrence type, time zone, recurrence weekdays, recurrence-until (UTC), reason, and creator. - The export is bounded (reject with 400 beyond 10,000 records, like the audit log export) and prefixed with a UTF-8 BOM so spreadsheets decode non-ASCII reasons correctly. - The maintenance-windows dialog gains an **Export windows** button that downloads the same file; existing list/create/end behaviour is unchanged. ## Acceptance criteria - [ ] `GET /api/alert-silences/export` returns `text/csv` with `Content-Disposition: attachment; filename="alert-silences.csv"` and a BOM-prefixed header row. - [ ] A one-time window serializes its labels (`key=value;key2=value2`), UTC bounds, reason and creator; a weekly window additionally serializes its recurrence type, time zone, sorted weekday list and recurrence-until. - [ ] Requests beyond the 10,000-record cap fail with 400 naming the limit instead of truncating silently. - [ ] The dialog button downloads the file through the shared blob download path and surfaces a failure message when the request fails. - [ ] Regression tests cover the CSV shape (service), the endpoint contract (controller) and the dialog button (page); existing silence list/create/end tests keep passing. ## Importance Should-have. The data is already in the store and readable page by page; what is missing is the one-click shareable form every neighboring inventory already has (alerts, deliveries, topics, consumer groups, DLQ, K8s certificates). The current workaround is manual transcription from a 10-row paginated dialog, which is slow, error-prone for recurring schedules, and effectively discourages attaching the silence list to incident reports at all. ## Duplicate check Searched open and closed issues/PRs for `silence export`, `"maintenance window" export`, `"alert silence" CSV`, `silences export`, and `alert CSV export`. The closest items are the alert-feed export (client-side, `exportAlerts` on the System Alerts page) and the notification-deliveries export (#3559 / #3770 lineage) — both export alert or delivery rows, not the maintenance-window inventory. No issue or PR proposes exporting the silences themselves. -- 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]
