unbridled-41 opened a new issue, #4558:
URL: https://github.com/apache/rocketmq-dashboard/issues/4558
### Before Creating the Issue
- [x] I have searched the open issues of this repository and believe this is
not a duplicate.
- [x] This is a defect in RocketMQ Studio.
### Studio Version
branch: `master`, commit `d50ffecc` (regression introduced with #4220)
### Describe the Bug
On any cluster with more than one broker master, `GET /api/liteTopic/list`
reports a `totalBacklog` (and `topicCount`) that covers only **one** master —
the last one whose `getBrokerLiteInfo` response mentioned the parent topic.
`discoverParentTopics` deliberately unions each parent topic's consumer
groups across masters ("A parent topic can be sharded across brokers … so union
across masters"), but `ParentTopicAccumulator` keeps only the last seen
`brokerAddr`, and `buildSummary` then issues a single
`getParentTopicInfo(parent.brokerAddr, …)` and a single `groupLag(admin,
parent.brokerAddr, group)` per group. The broker's `getLiteGroupInfo` handler
sums lag over its **own** `ConsumerOffsetManager` offset table only (verified
in the 5.5.1 broker bytecode: `LiteManagerProcessor.getLiteGroupInfo` →
`LiteConsumerLagCalculator.offsetTableForEachByGroup` →
`brokerController.getConsumerOffsetManager().getOffsetTable()`), so lag held by
the other masters is silently dropped. An actively lagging lite group on a
multi-broker cluster shows a near-zero backlog.
`topicCount` has the same defect:
`getParentTopicInfo(...).getLiteTopicCount()` counts the lite topics of one
broker only, while the groups were unioned across all of them.
### Steps to Reproduce
1. Two broker masters, one lite parent topic bound to a consumer group with
backlog on both masters (7 on broker-a, 4 on broker-b).
2. `GET /api/liteTopic/list`.
3. `totalBacklog` is 4 (only the last-scanned master) instead of 11.
### Impact
The list's only backlog metric is silently partial on the deployment shape
(sharded parent topics) the discovery code itself documents; operators see a
healthy-looking number for a lagging group.
### Related work
- #4220 (merged) introduced the provider and fixed the same class of
single-master inconsistency for the quota ratio ("build the lite quota ratio
from one consistent master set") — but not for the list aggregation.
- #4361 (open, claimed) is the same user-visible family: metric-read
failures/coverage gaps rendered as healthy numbers.
### PR
Fix incoming.
--
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]
