tju-yxq opened a new issue, #5200: URL: https://github.com/apache/rocketmq-dashboard/issues/5200
## Problem When a message is stuck or slow, the Message Explorer's trace tab is the tool that shows where time went — the per-stage timeline, the failure status of each stage, and the per-group consumer verdicts. But the result only lives on screen: sharing it with the broker team or attaching it to a support ticket means screenshots, because the console's only download action exports the message **body** alone (`handleDownload` in `web/src/pages/instance/message.tsx`, around line 730: `new Blob([formatBody(record.body)])` — not even the message metadata, and nothing of the trace). During an incident review this forces operators to re-type or screenshot stage timings and consumer failures, and the person receiving the ticket cannot re-derive the verdicts. ## Current behavior and reproduction 1. Open **Instance > Message**, query a message that has a trace (e.g. by Message ID). 2. Click the row's **轨迹** action: the detail modal opens on the trace tab and loads the stage timeline plus diagnostics. 3. The trace tab offers **查询轨迹** (re-query by another msgId/key, optionally against a custom trace topic) — but no export action of any kind. 4. The row's **下载** action saves only the raw body as `<msgId>.json`; the trace — nodes, timestamps, costs, statuses, consumer delivery results — cannot be saved or shared as data. ## Proposed behavior - The trace tab gains an **Export Trace** button next to the query action, enabled once a trace is loaded. - The download is a JSON document (not a screenshot): the query context (mode, msgId or key, topic, custom trace topic if any, instance) plus an `exportedAt` timestamp, the full `nodes` array (title, timestamp, cost, status, description) and the `consumerStatus` array (group, delivery status, consume time, retry count). - The filename identifies the trace (`trace-<msgId-or-key>.json`, sanitized for filesystem use). - Existing behaviour is unchanged: the per-message body download, the trace query controls and the diagnostics panel are untouched. ## Acceptance criteria - [ ] With a trace loaded, **导出轨迹** downloads a `trace-<identity>.json` file whose parsed JSON contains the query context (`mode`, `query`, `topic`, `traceTopic`, `instanceId`), an `exportedAt` timestamp, the full `nodes` array and the `consumerStatus` array. - [ ] The button is disabled while no trace is loaded and does nothing when disabled. - [ ] The identity in the filename falls back to the selected message's msgId when the trace was auto-loaded for it, and to the manually entered msgId/key when the trace was produced by a re-query. - [ ] Regression coverage asserts the exported payload shape (context, nodes, consumer status) through the shared blob download path; existing message-page tests keep passing. ## Importance Should-have. The workaround today is screenshots or manual transcription of stage timings, which loses the structured data (timestamps, costs, retry counts) and cannot be re-processed by whoever receives the ticket. Every other artifact an operator needs offline — the message body, DLQ exports, delivery exports — already has a download action; the trace is the one remaining incident artifact that is screen-only. ## Duplicate check Searched open and closed issues/PRs for `trace export`, `"message trace" download`, `trace JSON`, `轨迹 导出`, and `trace share ticket`. The closest matches are custom-trace-topic support (#2520/#4388 lineage, merged) and trace-diagnostics rendering (#2967 lineage, merged) — neither provides an export. No issue or PR proposes downloading the trace itself. -- 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]
