Frun1na opened a new issue, #6125: URL: https://github.com/apache/rocketmq-dashboard/issues/6125
### 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 ### Runtime Environment OS: Ubuntu on WSL2 MySQL: not applicable — the defect is in the producer group response contract and in the console rendering, not in persistence browser (for UI issues): not applicable — reproduced with jsdom in a vitest run ### Connected RocketMQ Cluster not applicable — reproduced with a stubbed broker admin client in a unit test. One broker answering `getAllProducerInfo` with an exception is enough; a real cluster with an unreachable or restarting broker produces the same shape. ### Describe the Bug `GET /api/producer/groups` returns the groups of the brokers it could reach and says nothing about the rest, so an incomplete scan is indistinguishable from a complete one. `RocketMQClientProvider.scanProducerGroups` already collects the addresses that failed (`RocketMQClientProvider.java:121-147`: `failedBrokers.add(brokerAddress)` in the catch, 502 only when *every* broker fails), but `findProducerGroups` returned `scanProducerGroups(...).groups()` and threw the list away. `ProducerConnectionService.listProducerGroups` then returned `List<String>` and the controller a bare array, so the marker had nowhere to go. Consequences: - the Producer page's producer group selector shows a short suggestion list with no indication that a broker's producers are missing — during a rolling restart the groups of the restarted broker simply vanish from the suggestions; - the empty case is ambiguous: "no producer groups" and "no broker answered" both render as an empty selector, while every other scan on the same page (producer connections) reports `INCOMPLETE_SCAN` and tags each failed broker. `#4468` fixed this for the producer connection scan and named this endpoint in its own commit message: "The producer group selector behind `/api/producer/group` still returns a partial list with no marker. Same defect class, but marking it means changing that endpoint's contract, so it is left for a follow-up." The existing test `RocketMQClientProviderTest.producerGroupSelectorKeepsBestEffortResultsWhenOneBrokerFailsTest` pins the current behaviour: it asserts the surviving group and never looks at the failed broker. ### Steps to Reproduce 1. Run the provider case added in the pull request below at `5e4c39b0` — the scan's own result already carries `127.0.0.1:10911` as failed, but nothing above the provider exposes it: `cd server && mvn -B -ntp test -Dtest=RocketMQClientProviderTest#producerGroupSelectorKeepsBestEffortResultsWhenOneBrokerFailsTest` 2. Or, against a live deployment with one broker stopped: `GET /api/producer/groups?instanceId=...&topic=...` returns a bare array of groups with no completeness information, and the Producer page's group selector lists only part of them. ### What Did You Expect to See? The endpoint should say that its list is partial, the way `/api/producer/connection` does for the same scan: a `complete` flag plus the brokers that could not be read, and the console should say so instead of presenting a short list as the whole inventory. ### What Did You See Instead? A bare `string[]` with no marker, an incomplete scan rendered as a complete list, and no way for the caller — console or API consumer — to tell the difference. ### Additional Context A fix with regression tests 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]
