unbridled-41 opened a new issue, #4905:
URL: https://github.com/apache/rocketmq-dashboard/issues/4905
### Before Creating the Bug Report
- [x] I searched the open **and closed** issues of this repository and
believe this is not a duplicate.
- [x] This is a defect in RocketMQ Studio, not a usage question and not a
defect in another Apache RocketMQ repository.
- [x] I can reproduce this on the `rocketmq-studio` trunk (the branch this
repository's CONTRIBUTING.md points at); the exact commit is stated below.
### Studio Version
```
branch: rocketmq-studio (reproduced on
1ef5d860799ac3fabfcdea942cc4dcc77ded7be6, the base of the fixing PR)
deployed as: built from source
```
### Runtime Environment
```
OS: Ubuntu 22.04 (WSL2)
MySQL: not required — the defect is in a pure frontend function and is
reproduced by a unit test
browser (for UI issues): not required
```
### Connected RocketMQ Cluster
```
RocketMQ version: not required
access mode: not required
deployment: not required — the input is a trace record, which the unit test
builds directly
```
### Describe the Bug
The message-trace diagnostics badge claims a delivery failure for a trace in
which nothing failed
to be delivered.
`analyzeMessageTrace` (`web/src/utils/messageTraceDiagnostics.ts`) returns a
`status` and a
`statusKey`, and the badge renders `statusKey` verbatim:
`<Tag …>{t(diagnostics.statusKey)}</Tag>` in
`web/src/pages/instance/message.tsx`. The `critical`
status has two unrelated sources:
- a **failure**: `FAILED_TRACE_NODE` (a phase whose status is `error`) or
`FAILED_CONSUMER_DELIVERY` (a consumer-status row with `deliveryStatus:
'failed'`);
- a **latency hotspot**: `SLOW_TRACE_NODE` where `costTimeMs >=
criticalNodeCostMs` (default 5000 ms)
or `SLOW_END_TO_END_TRACE` where `endToEndLatencyMs >= criticalEndToEndMs`
(default 30000 ms).
Before the fix, `STATUS_KEY` mapped the whole `critical` status to
`messagePage.traceStatusDeliveryCritical` = `投递异常 / Delivery Critical`
(`web/src/i18n/translations.ts`), so a trace of 31 s end to end whose
deliveries all succeeded and
whose phases all finished was badged:
> 消息轨迹诊断 **[投递异常]** 首尾轨迹阶段相隔 31000 ms …
The tag next to the badge describes a latency problem while the badge
asserts a delivery failure.
The neutral wording already exists — `messagePage.traceStatusCritical` = `异常
/ Critical`, and
`message.tsx` already uses it in a `diagnosticStatusKey` map for the
issue-severity column — but the
status badge does not use that map.
### Evidence / Source
Unit test added with the fix (a 3-node trace spanning 31 s, every phase far
below the 5 s critical
node cost, one successful delivery, asserted to carry no failure finding)
fails on the unfixed code:
```
$ cd web && npx vitest run src/utils/messageTraceDiagnostics.test.ts
× does not claim a delivery failure when only the latency is critical
AssertionError: expected 'messagePage.traceStatusDeliveryCritic…' to be
'messagePage.traceStatusCritical' // Object.is equality
Tests 1 failed | 5 passed (6)
```
Duplicate search: the neighbouring reports are #4745 (a trace looked up by
message key keeps the raw
failed node status — a different field), #2502 (merged: map failed trace
nodes to an error step) and
#4851 (an unreachable server-side `TrackType.UNKNOWN` → failed mapping);
none covers the badge text
of a latency-only critical, and no open PR touches
`messageTraceDiagnostics.ts`.
### Impact
The trace diagnostics panel of every message trace lookup in both UI
languages: an operator reading
a slow trace is told that a delivery failed and is sent to the
consumer/delivery subsystem instead
of the latency hotspot the adjacent tags describe.
### Expected Behaviour / Acceptance Criteria
- A critical trace whose critical findings are failures (failed trace node,
failed consumer
delivery) keeps the delivery wording `投递异常 / Delivery Critical`.
- A critical trace whose only critical findings are latency (slow node, slow
end-to-end) uses the
neutral `异常 / Critical`.
- `healthy` and `warning` labels, the status colour, the score and the issue
list are unchanged.
### Corresponding Pull Request
- #4900 — `fix(message): badge a critical trace by what is actually critical`
### Additional Context
Found while auditing the trace diagnostics status vocabulary against the
issues the same function
produces; the reproduction is the unit test above (no cluster, no MySQL, no
browser needed).
--
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]
