chennaji9 opened a new pull request, #6789: URL: https://github.com/apache/rocketmq-dashboard/pull/6789
### Which Issue(s) This PR Fixes None — small self-contained fix found by inspection (no issue tracked). ### Brief Description `rmq.proxy.config`'s manifest promises a snapshot "for one physical cluster", but the handler only used `clusterName` as an existence gate: ```java clusterResolver.require(input.clusterName()); // the resolved ManagedCluster was discarded Stream<ProxyTopologyVO> topology = proxyAddressService.buildTopology().stream(); // global registry ``` `buildTopology()` probes every address in the global proxy registry, which can hold the addresses of *every* managed instance at once. With instances A and B under management, a call addressing cluster A returned B's addresses too — and passing B's address in `addr` happily returned B's snapshot while asking for A. The resolved cluster never influenced the answer. The handler now keeps the `ManagedCluster` `require()` resolves and scopes the snapshot the way `rmq.proxy.list` already does: the probe set is `clusterProvider.discoverProxies(cluster.instanceId())` (deduplicated and trimmed), passed to a newly public `buildTopology(List<String>)` entry. `addr` filters within that scoped set and can no longer reach another instance's rows. The honest boundary is stated in the javadoc: heartbeat discovery proves instance scope, which is what "one physical cluster" can mean here; the global `buildTopology()` view the REST page uses is unchanged. ### How Did You Test This Change? `cd server && mvn -B -ntp test -Dtest='ProxyConfigToolHandlerTest,ProxyListToolHandlerTest,ProxyAddressServiceTest' -DfailIfNoTests=false` → **Tests run: 28, Failures: 0**. - `snapshotsTopologyForTheResolvedInstancesProxiesTest` — the service is probed with exactly the addresses the owning instance discovered (trim + dedup covered), and `verify` pins that argument; - `anAddrOutsideTheScopedSetFiltersToNothingTest` — asking for another instance's address yields an empty snapshot, not that instance's row. Red side: the leak expectation was run against the unfixed handler and fails — `Expecting empty but was: [ProxyConfigItem[addr=10.0.0.9:8081, status=DOWN, ...]]` — the global registry answered a cluster-A call with cluster B's proxy. Not run: `mvn test` on the whole module (integration tests need MySQL 8); the change is confined to one handler and one visibility widening, both covered above. ### Checklist - [x] One coherent change; unrelated modifications are not bundled in - [x] Commit subject follows Conventional Commits (`fix:`) - [x] Tests added or updated for non-trivial changes (scoped-set pin + out-of-scope filter, red-green) - [x] New UI text has both Chinese and English entries under `web/src/i18n/` (n/a — no UI change) - [x] Architecture constraints stay green (handler follows the existing `ProxyListToolHandler` discovery pattern; no new dependency) - [x] New source files carry the ASF license header (n/a — no new source file) - [x] Documentation touched where behaviour changed (handler javadoc states the instance-scope boundary; the tool-catalog wording is unchanged and now actually holds) 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- 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]
