Frun1na opened a new issue, #6095: URL: https://github.com/apache/rocketmq-dashboard/issues/6095
### 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: `5e4c39b0` deployed as: reproduced by unit tests against that commit (the affected code is the backend Apache provider) ### Runtime Environment OS: Ubuntu on WSL2 MySQL: not applicable — the defect is in the provider's discovery grading, reproduced in a JUnit 5 test with a stubbed admin client browser: not applicable ### Connected RocketMQ Cluster RocketMQ version: not applicable — reproduced with a stubbed `MQAdminExt`; the failing call is `examineConsumerConnectionInfo(CID_DefaultHeartBeatSyncerTopic)` access mode: not applicable deployment: not applicable ### Describe the Bug `RocketMQClusterProvider.discoverProxiesViaHeartbeatSyncer` turns every failure of the heartbeat-syncer read into an empty Proxy list: - `server/src/main/java/org/apache/rocketmq/studio/provider/apache/RocketMQClusterProvider.java:396-400` catches `Exception`, logs at debug and returns `Collections.emptyList()`. An empty list is what a cluster without a Proxy returns, so a caller cannot tell "this cluster runs no Proxy" from "the broker/NameServer could not be asked". The callers are `/api/proxies` consumers through `ClusterService.listProxiesForInstance` — where the failure then surfaces as `404 Proxy not found in instance …` from `ProxyAddressService.requireInstanceProxy` — and the `rmq.proxy.list` AI tool, which reports an empty inventory. The repository already grades this exact call everywhere else: - `ProxyConsumerResolver.discoverProxyAddressesStatus` (`provider/apache/ProxyConsumerResolver.java:194-201`) returns an empty address list only for `CONSUMER_NOT_ONLINE` / `TOPIC_NOT_EXIST` and marks anything else unavailable. - The same class grades its sibling calls: `discoverClustersAt` and `refreshClusterDetail` throw `BusinessException(502, …)` when the admin call fails, and the client-scan path added by #5453 answers 502 when the scan failed everywhere. ### Steps to Reproduce Stub `examineConsumerConnectionInfo("CID_DefaultHeartBeatSyncerTopic")` to throw, then call `discoverProxies("prod")`: ``` cd server && mvn -B -ntp -DforkCount=1 -Dtest=RocketMQClusterProviderTest test discoverProxiesShouldReportAHeartbeatSyncerReadFailureTest: Expecting code to raise a throwable. ``` ### What Did You Expect to See? An RPC-level failure is reported as an error (502) with the underlying cause, while a genuinely absent heartbeat-syncer group (`CONSUMER_NOT_ONLINE` / `TOPIC_NOT_EXIST` — a cluster that currently runs no Proxy) keeps returning an empty list. ### What Did You See Instead? Both cases return an empty list, so an unreachable broker is presented as "no Proxy is running". ### Additional Context A fix with a regression test follows in a pull request. ### 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]
