Frun1na opened a new issue, #6119: URL: https://github.com/apache/rocketmq-dashboard/issues/6119
### 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 a unit test 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 client-connection scan, reproduced in a JUnit 5 test with a stubbed admin client browser: not applicable for the reproduction; the Client page renders the affected flag ### Connected RocketMQ Cluster RocketMQ version: not applicable — the failing call is `getAllProducerInfo(brokerAddress)` on one broker of a stubbed two-broker cluster access mode: not applicable deployment: not applicable ### Describe the Bug `RocketMQClientProvider.findAllProducerConnections` (`server/src/main/java/org/apache/rocketmq/studio/provider/apache/RocketMQClientProvider.java:239`) logs a broker whose producer table could not be read and skips it, then returns the remaining rows without setting `ClientConnectionVO.partial` (only the all-brokers-failed case is graded, with a 502). `GET /api/clients` therefore answers with a list that is missing one broker's producers while it looks complete, and the Client page's partial-scan banner (`web/src/pages/cluster/clients.tsx:732`, driven by `connections.some(connection => connection.partial)`) stays off during a rolling restart. The two sibling paths in the same file already do this bookkeeping: `findConsumerConnections` (`:390-392`) sets `partial` on its rows when some group query failed, and `scanProducerGroups` (`:139-144`) reports `failedBrokers` — the producer-connection *scan* behind `/api/producer/connection` surfaces them as `complete` / `failedBrokers` since #4468. The client-list producer path was left out. ### Steps to Reproduce 1. Stub a two-broker cluster where one broker's `getAllProducerInfo` throws and the other returns one producer; call `findConnections(instanceId, clusterId, "Producer")`. 2. The single returned row has `partial == false`. 3. Or run the regression test, whose name already claims the partial result: ``` cd server && mvn -B -ntp test -Dtest=RocketMQClientProviderTest producerScanReturnsPartialResultsWhenOneBrokerFails: Expecting value to be true but was false ``` ### What Did You Expect to See? The returned rows carry `partial = true`, so the Client page says the inventory is incomplete — exactly what the consumer half of the same scan and the producer scan endpoint already do. Rows stay complete (`partial = false`) when every broker answers, and the all-brokers-failed case keeps answering 502. ### What Did You See Instead? An unmarked list: the producers of the unreachable broker are silently absent and nothing in the response tells the caller, so the page reports the shorter inventory as the whole picture. ### 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]
