tju-yxq opened a new issue, #6162:
URL: https://github.com/apache/rocketmq-dashboard/issues/6162
> Resubmission of #5217 — the original report was closed by the repo's 7-day
stale bot for inactivity, not because it was fixed or rejected; the problem is
still reproducible on the current `rocketmq-studio` head. An updated PR
carrying the fix is being filed against this report.
## Problem
The Message Explorer's row action **验证 / Verify** ("was this message
actually consumed, by which group, when?") is the question operators ask first
during incident triage — but the button only pops a warning:
"消费验证接口尚未接入，无法确认该消息的真实消费状态" (`handleVerifyConsume` in
`web/src/pages/instance/message.tsx`). Meanwhile the modal's verification tab
already renders the real per-group verdicts (group, delivery status, consume
time, retry count) from the trace's `consumerStatus` — the answer exists in the
product, the button just never reaches it.
Two additional defects in the same flow:
1. Opening the modal directly on the verification tab (`openDetail(record,
'consumer')`) shows an **empty table**, because only the trace tab triggers the
trace load — the verification tab depends on `traceData` that nobody loaded.
2. The verification table has no loading state, so even after switching tabs
the verdicts appear with no feedback in between.
## Current behavior and reproduction
1. Open **Instance > Message**, query a message that has a trace.
2. Click the row's **验证** action: a warning toast says the interface is not
available; nothing else happens.
3. Click **详情** and switch to the verification tab (labelled 验证): the table
is empty unless the trace tab happened to be opened first, and there is no
loading indicator while a trace loads.
`web/src/pages/instance/message.tsx`:
- `handleVerifyConsume` (around line 577) only calls
`message.warning(t('messagePage.verifyNotAvailable'))`.
- `openDetail` / `handleModalTabChange` load the trace only when the tab is
`'trace'` (around lines 624-638), while the verification tab's table reads
`traceData?.consumerStatus`.
## Proposed behavior
- The row's **验证** action opens the message detail modal directly on the
verification tab — the same verdict view that exists today behind the trace
tab, backed by the trace load.
- Opening the modal on the verification tab (or switching to it) triggers
the trace load, exactly like the trace tab, with the generation guard that
already protects against late/stale trace responses.
- The verification table shows its loading state while the trace loads.
- No new backend endpoint is needed and no verdict is fabricated: the tab
renders whatever the trace's `consumerStatus` reports.
## Acceptance criteria
- [ ] Clicking **验证** on a row opens the modal with the per-group verdicts
rendered (group, delivery status, consume time, retry count) — no "not
available" warning.
- [ ] Opening the modal on the verification tab (without visiting the trace
tab) still shows the verdicts, and the table shows a loading state until they
arrive.
- [ ] The existing late-response guards keep working: a trace that resolves
after the modal closes or switches messages does not populate the verification
tab.
- [ ] Regression coverage asserts the verify action calls the trace lookup
for the row's message and renders the verdicts; the existing trace-loading
tests keep passing.
## Importance
Must-have for the flow's integrity. The button exists in the UI and pretends
to offer verification but only reports unavailability, while the actual
verdicts sit one tab away behind data the page already knows how to load. The
workaround today is to open 详情, open the trace tab (to trigger the load), then
switch to the verification tab — three clicks through a flow that the dedicated
button was built to shortcut.
## Duplicate check
Searched open and closed issues/PRs for `"consume verification"`, `"verify
consume"`, `消费验证`, and `"not available" verify`. The closest match is #880
(closed, fixed by #881/#938): it removed the *fabricated* verification success
the button used to report — that fix deliberately left the button warning
instead of lying. This issue is the follow-up: connect the action to the real
verdicts the trace already returns, and fix the verification tab's missing
load. No open issue or PR covers wiring the verification action to real data.
--
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]
