Frun1na opened a new issue, #5668: URL: https://github.com/apache/rocketmq-dashboard/issues/5668
### 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 `master` branch, or I have stated the exact version I am running below. ### Studio Version branch: `rocketmq-studio` git commit id: `6a68042f` deployed as: built from source ### Runtime Environment OS: Ubuntu 22.04 (WSL2) MySQL: not applicable — the defect is in the producer-group selector endpoint browser: any (the selector is on the Producer page) ### Connected RocketMQ Cluster RocketMQ version: 5.x Apache cluster (the selector path is Apache-only; the cloud providers do not implement `ClientProvider`) access mode: direct to NameServer/Broker deployment: self-managed cluster ### Describe the Bug The producer-group selector endpoint accepts a `topic` filter and a `limit`, and reports neither that the topic is unused nor that the result was cut short or collected from a subset of brokers: - `ProducerConnectionService.listProducerGroups(instanceId, topic, query, limit)` forwards `topic` to `ClientProvider.findProducerGroups`, whose Apache implementation never reads it: `RocketMQClientProvider.findProducerGroups(adminExt, topic, query, limit)` returns `scanProducerGroups(adminExt, query, limit).groups()`. The topic the console sends (the Producer page re-fetches when the selected topic changes) therefore has no effect on the list. - `scanProducerGroups` sorts the collected names, applies `limit` (default 20, cap 100) with no signal, and returns `failedBrokers` in `ProducerGroupScanResult` — but the selector path drops them. Only the "every broker failed" case is graded (`502 Failed to query producer groups from all brokers`), so a partial scan is indistinguishable from a complete one. - The neighbouring connections path in the same service surfaces exactly those fields (`ProducerConnectionResultVO` with `complete` / `failedBrokers` / `failedProducerGroups`), so the two halves of the producer page disagree about what completeness looks like. - The response shape (`Result<List<String>>`) leaves no room for the signal, so any fix is a contract change: either the selector returns a VO like the connections path, or the unused parameter is dropped and the limit becomes explicit. An operator with more than 20 producer groups (or one broker temporarily unreachable) gets an alphabetically truncated list with no hint, cannot narrow it by topic, and may not find the group they are looking for. ### Steps to Reproduce 1. Open the Producer page for an Apache instance whose cluster has more than 20 producer groups, and pick a topic. 2. Open the producer-group selector: it lists at most 20 names, all from the whole cluster, none filtered by the selected topic, and says nothing about either fact. 3. Take one broker down and reload: the groups that broker hosted are simply missing; the response is still a plain 200 list. 4. `GET /api/producer/groups?instanceId=...&topic=<topic>` shows the same: `topic` changes nothing in the result. ### What Did You Expect to See? Either the topic filter working as advertised, or the parameter rejected/removed and the response telling the caller when the list is incomplete — the completeness channel the connections path already has. ### What Did You See Instead? A silently truncated, unfiltered list: `topic` accepted and ignored, `limit` applied without a `truncated` signal, and brokers that failed to answer dropped without a trace. ### Additional Context - the console cannot compensate: `web/src/api/producer.ts` sends the topic because the API declares it, and the selector has no way to tell a complete list from a cut-off one. - the fix needs a decision (contract shape, and whether the unused `topic` parameter is implemented or removed), which is why this is reported instead of patched: I am happy to implement whichever direction maintainers pick. ### 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]
