apache / apache/rocketmq-dashboard
[Studio][Feature] Show user properties on dead-letter messages in the DLQ drawer
- Dominant language
- Java
- Stars
- 1.4k
- Forks
- 683
- Avg merge
- 2d 14h
- Merged PRs (30d)
- 58
Description
1. Please describe the feature you are requesting.
The DLQ message drawer (`web/src/pages/instance/dlq.tsx`, backed by `GET /api/dlq/{groupName}/messages`) shows msgId, topic, queue, offset, store time, keys, and a truncated body — but no user properties. The Apache provider builds each `DLQMessageVO` from the full `MessageExt` it has already scanned (`RocketMQDLQProvider.toExportVO`), so the properties are in hand and simply dropped. The classic dashboard's DLQ detail dialog (`frontend-new/src/components/DlqMessageDetailViewDialog.jsx` on the `master` branch) renders the properties payload (including TAGS/KEYS).
2. Provide any additional detail on your proposed use case for this feature.
Business user properties are usually the only way to tell why one dead letter matters more than another (trace ids, tenant markers, retry counters). The resend path already values them: #1436 made DLQ resend preserve user properties. Displaying them in the drawer completes that picture without any extra broker call — the data is already scanned and in memory per request.
3. Indicate the importance of this issue to you (blocker, must-have, should-have, nice-to-have).
should-have. Workaround today is opening the Message Explorer, querying the `%DLQ%` topic manually, and opening each message there.
4. Expected behavior / acceptance criteria
- `GET /api/dlq/{groupName}/messages` returns each dead letter with a bounded `properties` map and a `propertiesTruncated` flag, using the same limits as the message explorer (64 entries max, 1024 characters per value, `...` suffix on clipped values).
- The DLQ drawer's message table gains expandable rows: messages with properties render the key/value list (with a truncation notice when flagged), messages without properties show an explicit "no user properties" fallback.
- No extra broker call: the properties come from the `MessageExt` records the DLQ scan has already fetched; the resend path (property-preserving since #1436) and the Excel/CSV export columns stay unchanged.
All of the above are covered by the tests listed in the PR.
5. Related PR
- #3999 (`feat(dlq): show user properties on dead-letter messages`) implements this request.
Contributor guide
No contributing guide indexed for this repository
Research direction
Start with web/src/pages/instance/dlq.tsx and the GET /api/dlq/{groupName}/messages entry point, then compare frontend-new/src/components/DlqMessageDetailViewDialog.jsx and the tests listed in PR #3999. Done means bounded properties and propertiesTruncated are returned, expandable drawer rows show values or an explicit no-properties fallback, and no extra broker call or export/resend regression is introduced.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java, javascript, typescript
- Domain
- backend-api-design, frontend
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Clearly specified
- Newbie friendliness
- 25/100