unbridled-41 opened a new issue, #5919:
URL: https://github.com/apache/rocketmq-dashboard/issues/5919
### Studio Version
branch: `rocketmq-studio` @ `7e7aa344` (the revision verified; the branch is
based on it)
deployed as: not required to reproduce
### Runtime Environment
Reproduced with the frontend tests (`cd web && npx vitest run
src/pages/instance/__tests__/ConsumerPage.test.tsx`); the live case needs a
group whose consume stats carry no consumed-message timestamp.
### Connected RocketMQ Cluster
Apache clusters with a group the broker reports no consumed-message
timestamp for - the provider names the case in its own comment ("No consume
stats (e.g. POP-only group without an offset table): keep zeros").
### Describe the Bug
`ConsumerGroupVO` carries two flags next to `delaySeconds`:
```java
/** Whether the provider successfully read broker-side consume stats for
this group. */
private boolean consumeStatsAvailable;
/** Whether broker consume stats include a consumed-message timestamp for
delay calculation. */
private boolean consumptionTimestampAvailable;
```
and the provider leaves `delaySeconds = 0` with `timestampAvailable = false`
when it cannot compute a delay. The console never read either flag (`grep -rn
consumptionTimestampAvailable web/src` -> no hits), so the 消费延迟 column and the
group drawer rendered `formatDelay(0)` = **0秒** - a claim that the group is
fully caught up - and the column sorted it among the genuinely caught-up
groups, first in an ascending scan. The sibling lag and client-count columns
already carry the "not measured" state (`totalLag`/`onlineInstances` = -1) and
render 不可用 for it.
### Steps to Reproduce
1. Open the consumer-group page for a cluster with a group whose consume
stats have no consumed-message timestamp.
2. The 消费延迟 cell reads 0秒; the detail drawer repeats it.
3. Sort by 消费延迟: the unmeasured group is ordered with the caught-up ones.
### What Did You Expect to See?
The delay reported as unavailable, like the lag and client-count columns do
for their own sentinel.
### What Did You See Instead?
A fabricated zero delay.
### Evidence
- `server/.../instance/group/ConsumerGroupVO.java:44-48`,
`server/.../provider/apache/RocketMQMetadataProvider.java:420-434`.
- `web/src/pages/instance/consumer.tsx` (the column and the drawer),
`web/src/api/metadata.ts` (the type lacked the field).
- `cd web && npx vitest run
src/pages/instance/__tests__/ConsumerPage.test.tsx -t 'consumed-message
timestamp'` - the new case fails before the fix.
### Impact
Groups whose delay cannot be measured are presented as caught up in the
list, the drawer and the sort order - the same "unknown collapsed into zero"
class the lag columns already fixed.
### Acceptance Criteria
- An unmeasured delay renders as unavailable, sorts after measured values in
both directions, and the field is declared on the client type, with a
regression test.
**Corresponding PR:** #ISSUEPR#
--
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]
