zmuxuny opened a new issue, #6186: URL: https://github.com/apache/rocketmq-dashboard/issues/6186
### 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 `master` branch, or I have stated the exact version I am running below. ### Studio Version rocketmq-studio@5e4c39b0, verified 2026-10-10. ### Runtime Environment Synthetic NameServer topology with mocked admin calls in RocketMQClusterProviderTest. No live broker contacted. Changed tests compiled against existing baseline artifacts, then run with Maven surefire:test. ### Connected RocketMQ Cluster Synthetic DefaultCluster -> broker-a and OtherCluster -> broker-b sharing one NameServer topology; selected default alias scope DefaultCluster. ### Build Toolchain _No response_ ### Describe the Bug A default physical-cluster alias backed by a shared NameServer applies different read scopes depending on endpoint. RocketMQClusterProvider.discoverClusters(instanceId) filters by RuntimeAdminClientResolver.configuredClusterName(instanceId), but refreshClusterDetail(clusterId, instanceId) and discoverBrokers(instanceId, brokerName) do not. InstanceResolver.resolveClusterName returns a physical cluster restriction only for default-cluster aliases. Registered instances intentionally return null and may expose multiple clusters. This is a default-alias selection consistency bug, not a claim about ACL security isolation. ### Steps to Reproduce Use one NameServer topology with DefaultCluster -> broker-a and OtherCluster -> broker-b, resolving the selected instance scope to DefaultCluster: 1. List clusters: restricted to DefaultCluster. 2. Query detail for OtherCluster: returns OtherCluster and reads broker-b runtime stats. 3. List brokers: returns broker-a and broker-b. 4. Explicit broker-b lookup succeeds outside selected scope. 5. A configured cluster absent from topology or missing membership metadata falls back to every broker. The REST detail controller/service forwards to provider; runtime resolver chooses endpoint/credentials without adding membership filtering. ### What Did You Expect to See? Apply configured default-alias scope consistently to detail and broker discovery. Outside-scope detail returns null without fetching other-cluster runtime stats. Broker discovery filters through configured NameServer membership; explicit outside-scope broker returns 404 and unavailable membership metadata reports 503 instead of returning all brokers. Preserve global/null-instance behavior and null configured-scope behavior of registered instances. ### What Did You See Instead? Against unchanged production code, RocketMQClusterProviderTest runs 24 tests: 5 new scope regressions fail, 19 pass, 0 errors. The new null-scope compatibility case passes. Only synthetic topology and mocked admin calls are used. ### Additional Context ### Reproduction details Equivalent normal command: `cd server && mvn -B -ntp -Dtest=RocketMQClusterProviderTest test`. The reproduction reused already-built baseline classes, compiled only the changed test class with javac, and ran Maven surefire:test. This is not a full clean build claim. ### Prior work and scope Credit: @X-LightYear's unmerged stale-closed PR #4995 (issue #4994) identified the detail-path inconsistency. This follow-up revalidates it on current trunk and covers the same missing configured-scope check in broker discovery. It does not change global cluster discovery. Audit found no active equivalent continuation. AI assistance was used for current-source analysis and regression authoring; attribution and Apache license headers will be retained. ### Are You Willing to Submit a Pull Request? - [x] Yes, I am willing to submit 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]
