apache / apache/rocketmq-dashboard
Notification deliveries cannot be exported
- Dominant language
- Java
- Stars
- 1.4k
- Forks
- 683
- Avg merge
- 2d 14h
- Merged PRs (30d)
- 58
Description
## Problem
Several operational inventories in the dashboard can be exported as CSV — topics, consumer groups, studio users, system alerts, and audit logs — but the notification delivery feed cannot. When operators need to share delivery failures with another team or attach them to an incident report, they currently have to copy rows manually.
## Current behavior and reproduction
1. Open **Ops > Notification Deliveries** after a notification incident.
2. Filter to the failing channel/instance.
3. Try to export the matching deliveries: the page has no export action, and the backend exposes no delivery export endpoint — only the paged `GET /api/system-alerts/deliveries/page`.
`web/src/pages/ops/notificationDeliveries.tsx` supports filtering, detail inspection, and retry actions, but has no export control.
## Proposed behavior
- Add `GET /api/system-alerts/deliveries/export` that reuses the channel, status, and instance filters from the delivery page.
- Export a bounded result set (at most 10,000 rows) ordered deterministically by delivery ID.
- Export the operationally relevant fields: delivery ID, alert ID/title/domain/transition, instance ID, channel, status, attempt count, creation/delivery/retry timestamps, and last error.
- Do **not** export full notification message content; the table and detail drawer fields are sufficient for incident review and avoid leaking complete alert payloads.
- Use the shared CSV writer so every cell is quoted and spreadsheet formula injection is prevented.
- Add an export button to the delivery page that downloads the currently filtered deliveries.
## Acceptance criteria
- [ ] The export endpoint applies the same channel/status/instance filters as the page.
- [ ] Export is bounded to 10,000 rows, ordered by delivery ID.
- [ ] Exported columns cover the listed fields; message content is not exported.
- [ ] CSV cells are quoted and formula-injection safe via the shared CSV utility.
- [ ] The page has an export button that requests the current filters and downloads the CSV.
- [ ] Backend tests cover filter propagation, row bound, field set, absence of message content, and CSV escaping.
- [ ] Frontend tests cover the export request and download.
## Importance
Should-have. Notification reliability reviews routinely require sharing the affected deliveries with another team. The current workaround is manual row copying, which is slow and produces inconsistent output.
## Duplicate check
Searched open and closed issues/PRs for `delivery export`, `notification delivery CSV`, `export deliveries`. No existing issue or PR adds export to the notification delivery feed.
Contributor guide
No contributing guide indexed for this repository
Research direction
Start with web/src/pages/ops/notificationDeliveries.tsx and the existing GET /api/system-alerts/deliveries/page flow, then trace the backend delivery endpoint and shared CSV writer. Add the filtered, bounded export and page action, and verify backend coverage for filters, fields, limits, escaping, and omitted message content plus frontend request and download tests.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java, typescript
- Domain
- api, backend, frontend, testing
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Clearly specified
- Newbie friendliness
- 70/100