unbridled-41 opened a new pull request, #4562:
URL: https://github.com/apache/rocketmq-dashboard/pull/4562
Fixes #4558.
## Problem / Evidence
`GET /api/liteTopic/list` reports a `totalBacklog` and `topicCount` that
cover only **one** broker master on multi-broker clusters.
`discoverParentTopics` unions each parent topic's consumer groups across
masters (its own comment: "A parent topic can be sharded across brokers … so
union across masters"), but `ParentTopicAccumulator` kept only the last-seen
`brokerAddr`, and `buildSummary` then issued a single
`getParentTopicInfo(parent.brokerAddr, …)` and a single `groupLag(admin,
parent.brokerAddr, group)` per group. The broker's `getLiteGroupInfo` sums lag
over its own `ConsumerOffsetManager` offset table only (rocketmq-broker 5.5.1
bytecode: `LiteManagerProcessor.getLiteGroupInfo` →
`LiteConsumerLagCalculator.offsetTableForEachByGroup` →
`brokerController.getConsumerOffsetManager().getOffsetTable()`), so lag held by
the other masters was silently dropped.
Red output on a two-master fixture (7 + 4 backlog): `expected: 11L but was:
4L`.
## Root cause / Fix
The aggregation contradicted its own documented shard semantics.
`ParentTopicAccumulator` now tracks the set of masters that advertised the
parent topic, and `buildSummary` gathers both the lite-topic count
(`getParentTopicInfo`) and the per-group backlog (`getLiteGroupInfo`) from
**every** master, summing the results — matching the union the discovery step
already applies to groups. The per-master reads keep their existing per-call
error grading (debug log + continue), so an unreachable master degrades instead
of failing the list.
## Priority & scoring
PRIORITY 70 = impact 26 (the only backlog metric for lite topics is silently
partial; the same user-visible family the project fixed as #4361) + reach 10
(lite topic list + table column) + repro 18 (deterministic two-master fixture)
+ maintain 16 (aligns the implementation with the documented union semantics
from #4220). FIX_CONFIDENCE 88 (straightforward per-master summation; covered
by a deterministic multi-master regression test).
## Tests
- New
`RocketMQLiteTopicProviderTest.listLiteTopicsSumsTheBacklogAcrossEveryMasterTest`
(two masters, lags 7 + 4):
- Red: `Tests run: 1, Failures: 1` — `expected: 11L but was: 4L`.
- Green: asserts `totalBacklog == 11`.
- Full provider class: **15/15**; `LiteTopicServiceTest`: **10/10**.
- Full backend suite (`SPRING_PROFILES_ACTIVE=dev mvn clean test`): 2395
tests, 0 failures — identical to the `origin/master` baseline (this change adds
no net new test count to the suite totals above beyond the documented
additions).
## Risk
Low. Extra per-master RPCs per listed parent topic are bounded by the
existing scan caps (`MAX_LITE_TOPIC_SCAN`, groups per parent); single-master
deployments issue the same calls as before.
--
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]
