unbridled-41 commented on PR #4900:
URL:
https://github.com/apache/rocketmq-dashboard/pull/4900#issuecomment-5775351198
### Verification pass — clean checkout of `fb3db8dd`
Re-verified from a fresh `git worktree add --detach
fork/fix/trace-critical-delivery-label`
(own checkout and build output; only `web/node_modules` symlinked).
#### One description defect found and corrected
The description claimed that the `diagnosticStatusKey` map in `message.tsx`
"is simply never
reached". That is **wrong**: the map is used, at `message.tsx:289`, for the
*issue-severity* column
of the diagnostics table. What is true is narrower and is what the fix
relies on: the *status badge*
(`message.tsx:229`) renders the util's `statusKey` instead of that map, so a
latency-only critical
gets the delivery wording. The paragraph has been rewritten to say exactly
that, and the sentence
has been re-checked against the file in this checkout:
```
$ sed -n 211,215p web/src/pages/instance/message.tsx #
diagnosticStatusKey, critical -> messagePage.traceStatusCritical
$ sed -n 229p web/src/pages/instance/message.tsx # badge:
t(diagnostics.statusKey)
$ sed -n 289p web/src/pages/instance/message.tsx # severity
column: t(diagnosticStatusKey[severity])
$ grep -n "traceStatusCritical\|traceStatusDeliveryCritical"
web/src/i18n/translations.ts
575: 'messagePage.traceStatusCritical': { zh: '异常', en: 'Critical' },
595: 'messagePage.traceStatusDeliveryCritical': { zh: '投递异常', en: 'Delivery
Critical' },
```
#### Citations re-read
The fix shifts the file, so the description now labels every citation as
*base commit* / *branch*.
Re-verified here with `grep -n` against both revisions:
| Site | Base `1ef5d860` | Branch |
|------|-----------------|--------|
| `FAILED_TRACE_NODE` issue | `:204` | `:228` |
| `FAILED_CONSUMER_DELIVERY` issue | `:364` | `:388` |
| `severityForLatency` (critical ternary) | `:188-193` | `:212-217` |
| `SLOW_TRACE_NODE` via `severityForLatency` | `:252-253` | `:276-277` |
| `SLOW_END_TO_END_TRACE` | `:525-526` | `:549-550` |
| `STATUS_KEY` (pre-fix `critical: '…DeliveryCritical'`) | `:118-122` |
`:118-122` (generic key) |
| `statusKey: STATUS_KEY[status]` → `statusKey: statusKeyFor(status,
issues)` | `:565` | `:589` |
`DELIVERY_CRITICAL_CODES` is at `:125-128` and `statusKeyFor` at `:132-146`
on the branch.
#### Tests re-executed in the clean worktree
```
$ npx vitest run src/utils/messageTraceDiagnostics.test.ts
Test Files 1 passed (1)
Tests 6 passed (6)
$ npx vitest run src/utils src/pages/instance/__tests__/MessagePage.test.tsx
src/pages/instance/__tests__/MessagePageAsyncState.test.tsx
Test Files 22 passed (22)
Tests 164 passed (164)
$ npx tsc -b && npx eslint src/utils/messageTraceDiagnostics.ts
src/utils/messageTraceDiagnostics.test.ts
(no output, exit 0)
```
#### Pre-fix behaviour re-demonstrated
New test kept, only `web/src/utils/messageTraceDiagnostics.ts` restored to
`origin/rocketmq-studio`:
```
× 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)
```
#### Coverage note
The new case pins the latency-only critical (31 s end to end, every phase
under the 5 s critical node
cost, all deliveries successful, asserted to carry no
`FAILED_TRACE_NODE`/`FAILED_CONSUMER_DELIVERY`
finding). The existing case for a failed consumer node still asserts the
delivery wording, so the
two branches of `statusKeyFor` are both covered. Not covered: a trace whose
only critical is a
non-consumer failed node (e.g. a failed producer step) keeps the delivery
wording — that is the
pre-existing behaviour of the badge for any failure, left unchanged on
purpose.
No commit was needed for this PR: the correction was description-only.
--
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]
