iloveeyjafjalla opened a new pull request, #6853:
URL: https://github.com/apache/rocketmq-dashboard/pull/6853
## Which Issue(s) This PR Fixes
Fixes #6852
## Problem / Evidence
`GET /api/clusters` and `GET /api/clusters/{id}` answered `topicCount: 0`
and `groupCount: 0` for every cluster:
```json
{"id": "DefaultCluster", "name": "DefaultCluster", "status": "healthy",
"version": null, "topicCount": 0, "groupCount": 0}
```
No cluster path measures them:
`provider/apache/RocketMQClusterProvider.buildClusterVO` hardcoded
`.topicCount(0).groupCount(0)`,
`cluster/broker/RealClusterProvider.toClusterVO` never set them, and
`ClusterRepositoryImpl` only copied them through - the sole non-zero values in
the tree were the demo fixtures it built itself. Both fields are primitives, so
`0` was indistinguishable from "measured: no topics".
The same cluster's measured numbers are already served by the overview:
```
GET /api/clusters?instanceId=local-broker -> {"topicCount": 0,
"groupCount": 0}
GET /api/dashboard?instanceId=local-broker -> {"name": "DefaultCluster",
"topics": 32, "groups": 1}
```
## Fix
Drop the two counts from `ClusterVO` (and the javadoc says why they are
absent), from the provider and the repository together with its demo fixtures,
from `docs/api-spec.md`, and from the web type / service / mock / fixtures.
This is the call #6101 makes for the topic statistics no provider computes: a
count nobody produces is better absent than serialized as a measured `0`.
## Tests
New `ClusterResourceCountsTest` serializes the view and asserts the payload
carries neither count, plus that the core keys are still there so the assertion
cannot pass on an empty payload. With a count temporarily re-added to the view:
```
[ERROR] ClusterResourceCountsTest.clusterViewClaimsNoResourceCountTest --
<<< FAILURE!
[ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0
```
With the change (JDK 21, offline Maven), every test class that mentions
`ClusterVO`:
```
Tests run: 155, Failures: 0, Errors: 0, Skipped: 0
ClusterControllerTest 34, ClusterServiceTest 43,
RocketMQClusterProviderTest 30, NameServerConfigDiffServiceTest 14,
RealClusterProviderTest 9, BrokerConfigDiffServiceTest 8,
ClusterRepositoryImplTest 5, ClusterServiceRegistryTest 5,
ApacheRocketMqProxyMetricsCollectorTest 3, ClusterConnectionServiceTest 2,
ClusterResourceCountsTest 1, RegistryProbeRunnerTest 1
```
Web side: `npx tsc -b` clean, `npm run lint` clean, and the six
cluster-related test files pass (`clusterContract`, `clusterStats`,
`ClusterPage`, `ClientsPage`, `BrokerCluster`, `BrokerClusterInstanceScope`). A
full `npm test` on this machine also reports unrelated, load-dependent 20s
timeouts in pages this PR does not touch - a different subset each run, and the
same files pass when run alone or on the base revision, so they are environment
flakiness rather than a regression here.
One note for whoever reviews this together with #6833: that PR pins the
cluster key set and its `DOCUMENTED_FIELDS` still lists these two names. If it
is open when this lands, those two entries need to go with the fields.
Verified against the running stack at `a92c2314`; the change was prepared
with AI assistance and reviewed, tested and verified by me.
--
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]
