unbridled-41 opened a new issue, #5005:
URL: https://github.com/apache/rocketmq-dashboard/issues/5005

   ### Studio Version
   
   branch: rocketmq-studio
   git commit id: 1ef5d860799ac3fabfcdea942cc4dcc77ded7be6
   
   ### Runtime Environment
   
   Reproducible at the unit level against a mocked `DefaultMQAdminExt` 
(RocketMQClientProviderTest); needs a real broker only for manual confirmation 
of the admin API shapes.
   
   ### Connected RocketMQ Cluster
   
   Any Apache instance with two producer groups where only one ever produced to 
the selected topic.
   
   ### Describe the Bug
   
   `GET /api/producer/groups` declares a `topic` parameter 
(`ProducerController.java:37-43` at 1ef5d860) and the Producer page always 
sends the selected topic (`Producer.tsx:187-191`), but the provider drops it: 
`RocketMQClientProvider.findProducerGroups` 
(`RocketMQClientProvider.java:114-116`) immediately calls 
`scanProducerGroups(adminExt, query, limit).groups()` — `topic` is never read. 
The scan (`:118-145`) collects every group from 
`getAllProducerInfo(brokerAddress)` across all brokers; the producer table 
(`ProducerTableInfo`, rocketmq-remoting 5.5.1) is keyed by group only, so no 
topic dimension exists anywhere in the path.
   
   The follow-up connection query examines **(group, topic)** pairs 
(`examineProducerConnectionInfo`, provider `:189`), so most suggested groups 
return an empty connection list: the selector suggests a group that never 
produced to the topic, and picking it yields nothing.
   
   ### Steps to Reproduce
   
   1. Open the Producer page on an instance where group `pg-order` produces to 
topic `T1` and group `pg-payment` never touches `T1`.
   2. Select topic `T1` and focus the producer-group selector.
   3. Observe that `pg-payment` is offered as a suggestion.
   4. Pick it: the connection list comes back empty.
   
   ### What Did You Expect to See?
   
   A topic-scoped selector offers only groups that have producer connections on 
the requested topic (RocketMQ exposes no topic→producer-group admin API, so 
candidates must be verified per group); with no topic requested, the current 
whole-broker scan remains correct.
   
   ### What Did You See Instead?
   
   Every producer group in the cluster is suggested regardless of the selected 
topic.
   
   ### Additional Context
   
   Boundary check against existing reports: #4168 is about connection *results* 
surviving a topic switch (different surface), #2767 (closed) about suggestion 
string normalization — neither covers the dropped `topic` parameter in the 
provider.
   
   Corresponding pull request: #5001.


-- 
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]

Reply via email to