btlqql opened a new issue, #4293:
URL: https://github.com/apache/rocketmq-dashboard/issues/4293
## 1. Symptom
`GET /api/topics/{name}/consumers/page` (`TopicController` ->
`MetadataService.getTopicConsumersPage` ->
`RocketMQMetadataProvider.getTopicConsumersPage`) publishes the internal
"lag unknown" sentinel `-1`
as a real backlog while flagging the metrics as available.
For any consumer group whose queue offsets make the resolved lag unknown (a
RocketMQ 5.0 gRPC/POP
consumer whose queue reports `brokerOffset - consumerOffset < 0`), the
response contains
```json
{ "group": "cg-orders", "diffTotal": -1, "metricsAvailable": true }
```
and the topic page renders the 堆积量 column as `-1` instead of the unavailable
marker
(`web/src/pages/instance/topic.tsx:927-932` renders `不可用` only when
`record.metricsAvailable === false`).
## 2. Root cause
`server/src/main/java/org/apache/rocketmq/studio/provider/apache/RocketMQMetadataProvider.java:530-543`
```java
long diffTotal = 0;
...
long queueDiff = resolveDiff(ow.getBrokerOffset(), ow.getConsumerOffset());
if (queueDiff == ConsumerLagResolver.UNKNOWN) {
diffTotal = ConsumerLagResolver.UNKNOWN;
break;
}
...
consumers.add(TopicConsumerVO.builder()
.consumeTps(consumeTps)
.diffTotal(diffTotal)
.build());
```
`TopicConsumerVO.metricsAvailable` is `@Builder.Default` `true`
(`instance/topic/TopicConsumerVO.java:35-36`), and this branch never
overrides it. The sibling
failure branch in the same method does (`metricsAvailable(false)`), so the
two ways of "I could not
read the numbers" report differently.
This is the one place the sentinel still reaches a user as a quantity: the
consumer-group paths
convert it (`MetadataService.lagText` returns `unknown`,
`ConsumerGroupListToolHandler:64` returns
`null`), and `ConsumerLagResolver`'s own javadoc states that the sentinel
exists so the UI can show
the genuine unknown state instead of a fabricated number.
## 3. Impact
- A group with an undeterminable lag shows a backlog of `-1`, which looks
like a broken metric and
hides the real state (the operator cannot tell "unknown" from "1 message
in flight").
- The metric flag is inconsistent: the same unknown condition renders as
`-1` on the topic consumer
page and as `unknown` in the consumer-group CSV export and the dashboard.
## 4. Reproduction
1. Have a group with a POP/gRPC consumer whose queue reports `brokerOffset =
99`,
`consumerOffset = 100` (or any negative raw diff with no proxy stats
available).
2. Open the topic page's consumer tab for that topic, or call
`GET /api/topics/{name}/consumers/page`.
3. `diffTotal` is `-1` and `metricsAvailable` is `true`.
## 5. Expected behaviour
- `metricsAvailable` is `false` for a group whose lag could not be
determined, so the existing UI
contract renders the unavailable state.
- `diffTotal` keeps carrying `ConsumerLagResolver.UNKNOWN` for callers that
read it directly, and
known-lag sums are unchanged.
--
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]
