unbridled-41 opened a new pull request, #5001:
URL: https://github.com/apache/rocketmq-dashboard/pull/5001
## Problem
`GET /api/producer/groups` declares a `topic` parameter
(`ProducerController.java:37-43`), the Producer page always sends the selected
topic (`Producer.tsx:187` -> `fetchProducerGroups(instanceId, { topic:
selectedTopic, query, limit })`), and the follow-up connection query examines
**(group, topic)** pairs. But the provider dropped the topic on the floor:
- base `1ef5d860`, `RocketMQClientProvider.java:114-116`:
`findProducerGroups(adminExt, topic, query, limit)` ->
`scanProducerGroups(adminExt, query, limit).groups()` — `topic` unused.
- `scanProducerGroups` (`:118-145`) scans
`getAllProducerInfo(brokerAddress)` across all brokers; the producer table is
keyed by **group only** (`ProducerTableInfo.getData()`), so no topic
information exists anywhere in the path.
Result: with groups `pg-order` (producing to topic T1) and `pg-payment`
(never touching T1), the T1-scoped selector suggested both; picking
`pg-payment` then ran `examineProducerConnectionInfo("pg-payment", "T1")`,
which returns nothing — the operator picks a suggestion and gets an empty
connection list, with the selector contradicting the result pane.
## Root cause
The topic parameter is threaded through the API surface
(`ClientProvider.findProducerGroups(instanceId, topic, query, limit)`) but
dropped at the first private helper. RocketMQ exposes no topic->producer-group
admin API, so a topic-scoped selector has to verify candidates.
## Fix
When a topic was requested, verify each scanned candidate with the same
admin query the follow-up uses (`findProducerConnectionsForGroup(adminExt,
topic, group)`), keeping only groups that have connections on that topic; a
missing connection is the normal empty outcome
(`isTopicNotExist`/`isGroupConnectionAbsent` already map to empty) and a failed
verification skips that group rather than failing the selector. Without a topic
the cheap whole-broker scan is kept unchanged — suggestions then have no topic
semantics to violate.
The two legacy selector tests passed `"TopicA"` while asserting
`verify(adminExt, never()).examineProducerConnectionInfo(...)` — pinning the
bug itself — so their topic argument is dropped; their sort/dedup/limit and
best-effort intent is unchanged and now additionally covered by the explicit
no-topic test.
## Scoring (AGENTS.md)
PRIORITY **56** = impact 22 (a core selector suggests wrong groups and
picking them yields empty results) + reach 10 (Producer page group selector) +
reproducibility 14 (deterministic whenever two groups disagree on the topic) +
maintainability value 10 (restores the parameter's contract). FIX_CONFIDENCE
**85**: reuse of the existing per-group query; the only judgement call
(skip-vs-fail on a verification error) is logged and keeps the whole selector
best-effort, matching the existing broker-failure semantics.
## Tests
- New: `producerGroupSelectorScopesSuggestionsToTheRequestedTopicTest` —
pre-fix fails on the off-topic group being suggested (`but some elements were
not expected: ["pg-payment"]`); new
`producerGroupSelectorKeepsAllMatchesWhenNoTopicIsRequestedTest` pins the
no-topic scan.
- Post-fix: `mvn -o -Dtest=RocketMQClientProviderTest test` -> **Tests run:
32, Failures: 0 - BUILD SUCCESS**; `ProducerConnectionServiceTest` +
`ProviderStubContractTest` -> **19/19**.
## Risk
Low-medium. With a topic set, the selector performs one extra
`examineProducerConnectionInfo` per candidate group (bounded by `limit`,
default 20) — the same broker round-trips the follow-up query pays anyway.
Suggestion latency on clusters with many groups is the main cost; the no-topic
path is untouched.
--
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]
