Frun1na opened a new issue, #6528:
URL: https://github.com/apache/rocketmq-dashboard/issues/6528

   ### Before Creating the Bug Report
   
   - [x] I have searched the [open 
issues](https://github.com/apache/rocketmq-dashboard/issues) of this repository 
and believe that this is not a duplicate.
   - [x] This is a defect in RocketMQ Studio, not a usage question and not a 
defect in another Apache RocketMQ repository.
   - [x] I can reproduce this on the current `rocketmq-studio` branch, or I 
have stated the exact version I am running below.
   
   ### Studio Version
   
   branch: `rocketmq-studio`
   git commit id: `779b8c0e`
   deployed as: reproduced with a stubbed admin client in a unit test against 
that commit
   
   ### Runtime Environment
   
   OS: Ubuntu on WSL2
   MySQL: not applicable — the defect is in the dashboard aggregation over the 
NameServer topology
   browser (for UI issues): not applicable
   
   ### Connected RocketMQ Cluster
   
   RocketMQ version: not applicable — reproduced with a stubbed `MQAdminExt`
   access mode: Direct to NameServer (the dashboard collects 
`examineBrokerClusterInfo()`)
   deployment: one NameServer serving two clusters (cluster-a, cluster-b), 
exercised through a stubbed admin client
   
   ### Describe the Bug
   
   `RocketMQDashboardProvider.getDashboardData(String instanceId)` 
(`server/.../provider/apache/RocketMQDashboardProvider.java:185-192`) 
aggregates the whole `examineBrokerClusterInfo()` topology without applying the 
cluster the instance is configured for:
   
   - `collectDashboardData` reads `clusterAddrTable` and `brokerAddrTable` 
verbatim (`:214-219`), builds `masterAddrs` from every broker (`:242-256`) and 
then sums topics, consumer groups, TPS and daily messages over all of them, 
plus one overview row per cluster (`:357` onwards).
   - The other instance-scoped reads of the same provider already narrow: 
`discoverClusters` filters to the configured cluster 
(`RocketMQClusterProvider.java:88-91`), and `786a308e` (#6196) extended that to 
`refreshClusterDetail` and `discoverBrokers`, naming the dashboard as one of 
the readers left for a separate change ("Other topology readers still see the 
whole cluster table (`ApacheRocketMqClusterMetricsCollector.java:75`, 
`RocketMQDashboardProvider.java:207`, `ApacheAclReadService.java:41`)").
   - `InstanceResolver.resolveClusterName` returns the cluster name for a 
default-cluster identifier (`defaultClusters.find`), and 
`RocketMQDashboardProvider` is reachable with such an identifier — so an 
operator who selects cluster A sees cluster B's brokers, topics and TPS in A's 
overview while the cluster and broker pages correctly show only A.
   
   ### Steps to Reproduce
   
   The defect is pinned by a unit test; no live cluster is needed:
   
   ```
   cd server
   mvn -B -ntp test -DforkCount=1 -Dtest=RocketMQDashboardProviderTest
   ```
   
   `dashboardShouldNarrowTheTopologyToTheClusterConfiguredForTheInstanceTest` 
stubs one NameServer with cluster-a (broker-a, 10.0.0.11) and cluster-b 
(broker-b, 10.0.0.12), resolves `instance-local` to cluster-a and asserts a 
single overview row, `totalBrokers = 1` and that the cluster-b broker is never 
read (`getAllTopicConfig` / `getAllSubscriptionGroup` / 
`fetchBrokerRuntimeStats` on 10.0.0.12). Before the fix it fails with `Expected 
size: 1 but was: 2`; the control 
`dashboardShouldExposeEveryClusterForAnInstanceWithoutAConfiguredClusterTest` 
keeps the unscoped behaviour pinned.
   
   ### What Did You Expect to See?
   
   An instance-scoped dashboard should summarise only the clusters the instance 
is scoped to, the way `discoverClusters`, `refreshClusterDetail` and 
`discoverBrokers` already do. If the configured cluster is absent from the 
topology, its row should degrade to a warning (as the aggregate dashboard 
already does for unreachable instances) instead of silently including other 
clusters.
   
   ### What Did You See Instead?
   
   The overview's totals and per-cluster rows include every cluster of the 
shared NameServer — brokers, topics, consumer groups, TPS, daily messages and 
the cluster count — so the page contradicts the cluster and broker pages of the 
same instance.
   
   ### Additional Context
   
   A fix with regression tests follows in a pull request.
   


-- 
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]

Reply via email to