Frun1na opened a new issue, #6795: URL: https://github.com/apache/rocketmq-dashboard/issues/6795
### 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: a92c2314 deployed as: reproduced by a unit test against that commit ### Runtime Environment OS: Ubuntu on WSL2 (linux/amd64) MySQL: not applicable - the defect is in the MCP tool handler layer browser (for UI issues): not applicable ### Connected RocketMQ Cluster not applicable - reproduced with a stubbed ClusterProvider in a unit test ### Describe the Bug `rmq.broker.list` and `rmq.proxy.list` aggregate across every manageable Instance when no `clusterName` is supplied, and an Instance whose discovery throws is skipped with a server-side warning only: `BrokerListToolHandler.execute` (`server/src/main/java/org/apache/rocketmq/studio/ops/ai/tool/handler/broker/BrokerListToolHandler.java:74-81`) and `ProxyListToolHandler.execute` (`.../handler/proxy/ProxyListToolHandler.java:71-78`) catch the exception, log `Skipping instance ...`, and continue. The result is `ListOutput<>(items)` - there is no `complete`/`failedInstances` field in the record or in the two tool catalog output schemas - so a caller cannot tell an inventory that is missing a whole Instance from a complete one, and an unreachable Instance reads as one that has no brokers (or proxies). The same scan shape elsewhere in the codebase already reports this: the producer-connection scan returns `complete` plus `failedBrokers`/`failedProducerGroups` (added by #4468 and surfaced by its tool), and the platform dashboard degrades an unreachable Instance to a warning row instead of dropping it. ### Steps to Reproduce 1. Register two Apache Instances, make the first one's discovery fail (unreachable NameServer or bad credentials). 2. Call `rmq.broker.list` (or `rmq.proxy.list`) without `clusterName`. 3. Observe the result: only the second Instance's brokers are present, and nothing in the payload says the first Instance was skipped. 4. Or run the unit test: `mvn -B -ntp test -Dtest=BrokerListToolHandlerTest,ProxyListToolHandlerTest -DforkCount=1`; against a92c2314 both `skipsFailingInstancesDuringAggregationTest` cases fail with `Expecting map: {"items"=[...]} to contain entries: ["scan"={"complete"=false, "failedInstances"=["instance-down"]}] but could not find the following map entries` - the response has no channel to carry that fact. ### What Did You Expect to See? The result names the Instances that could not be scanned and marks itself incomplete - one field a caller can branch on, the way the producer-connection scan reports `complete`/`failedBrokers`, and `unreachable` is never silently indistinguishable from `no brokers`. ### What Did You See Instead? A partial list presented as the whole inventory: the failing Instance is absent from `items` and appears nowhere else in the response, so the tool answers "these are the brokers in Studio" while one Instance was never read. ### Additional Context A fix with regression tests follows in a pull request: a `ScanOutput` contract (`items` plus a `scan` block with `complete`/`failedInstances`) for the two tools, their catalog output schemas, and the regenerated catalog. The scan block is nested so the CLI's table view keeps its single array property. ### 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]
