unbridled-41 opened a new issue, #4745:
URL: https://github.com/apache/rocketmq-dashboard/issues/4745
### Studio Version
branch: rocketmq-studio
git commit id: cd448e17f14b4bd6e6d4ade87300caf19ca91bc2
### Problem
A message trace looked up by **Message Key** keeps the broker's raw node
status, so a failed node is rendered and graded as a healthy one. The
message-id lookup and the key lookup share the same nodes from the same
provider, but only the message-id wrapper normalises the status through
`mapTraceNodeStatus` (`failed` -> `error`).
Chain:
- `web/src/api/message.ts:150-156` — `mapTraceNodeStatus` maps the backend
business statuses onto the four statuses Ant Design `Steps` understands and is
documented as "Map at the API boundary so the UI never sees a status it cannot
render".
- `web/src/api/message.ts:172-179` — the message-id lookup applies it to
every node.
- `web/src/api/message.ts:200-201` — `getMessageTraceByKey` returned
`res.data.data` verbatim, so the nodes keep `"failed"`.
- Both endpoints serve the same nodes: `MessageController.java:71-77`
(`/messages/trace-by-key`) and `:53-58` (`/{msgId}/trace`) both call the
provider, whose trace parser emits only `"finish"`/`"failed"`
(`server/.../provider/apache/RocketMQMessageProvider.java:713,728,762`;
`MessageTraceStatusEnum.FAILED = "failed"`).
- `web/src/pages/instance/message.tsx:646-654` — both lookups feed the same
`setTraceData(result)`, so the modal renders whichever statuses arrived.
- `web/src/pages/instance/message.tsx:1003` passes `status: node.status`
straight to `Steps`, and `web/src/utils/messageTraceDiagnostics.ts:220-229`
only recognises `'error'` as a failed phase, so a `"failed"` node produces
neither the failed step styling nor a `FAILED_TRACE_NODE` issue.
Trigger (deterministic): open a message detail, switch the trace selector to
`Key`, query a key whose trace contains a failed node (e.g. a message the
consumer never acknowledged). The identical trace queried by message id is
reported as critical; by key it renders as a normal step and the diagnostics
panel reports the trace as healthy.
### Evidence
- `web/src/api/message.ts:200-201` — the defect: the by-key wrapper returned
the response without mapping.
- `web/src/api/message.ts:173-179` — the sibling path that does map, added
by #2576 (`8c0079be fix(trace): map failed trace nodes to the error step
status`) for the message-id lookup only; the key lookup itself predates that
fix (#2520, `96ad1b06`), so the mapping was never extended to it.
- `web/src/pages/instance/message.tsx:646-654` and `:1003`,
`web/src/utils/messageTraceDiagnostics.ts:220-229` — the two consumers of the
unmapped status.
- Regression test added with this report (`web/src/api/message.test.ts`,
"maps backend trace node statuses on the key lookup too"), failing before the
fix:
```
AssertionError: expected [ Array(3) ] to deeply equal [ 'error', 'finish',
'wait' ]
- Expected + Received
[ - "error" + "failed", "finish", - "wait" + "something-else" ]
```
### Impact
A trace that failed at a node is presented as healthy whenever it is looked
up by key: the step renders without the error state and the trace diagnostics
panel reports no critical issue, so an operator debugging a lost message is
told the trace is fine. The message-id lookup of the same message reports the
failure, so the same data has two answers depending on how it was found.
### Expected behavior
The key lookup normalises node statuses exactly like the message-id lookup,
and keeps returning `null` when no trace exists for the key.
### Related work
- #2576 (`8c0079be`) — mapped the message-id path; this report completes the
key path that was added earlier and never covered.
- #4483 / #3297 (open) — bound the trace request cache; same endpoints,
different defect.
- #3305 (open) — `NO_MESSAGE` grading for empty key/trace lookups; the
empty-result path, not the node status.
#
## PR
Fix: #4742.
This PR targets the development trunk `rocketmq-studio`. GitHub interprets
closing keywords only for pull requests that target the repository default
branch, and this repository default branch is still `master`, so merging the PR
will not close this issue automatically — it needs to be closed by hand.
--
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]
