Aias00 opened a new issue, #4463:
URL: https://github.com/apache/rocketmq-dashboard/issues/4463
## Problem
`GET /api/producer/connection` supports a topic-only query by discovering
every active producer
group and querying each group for its connections. When one group RPC fails
but another succeeds,
`RocketMQClientProvider.findProducerConnectionsForActiveGroups` logs and
skips the failed group, then
returns HTTP 200 with the remaining connections.
The response has no completeness marker or failed-group list, so operators
can mistake a partial
inventory for the complete active producer set. An empty successful result
from one group is enough
to suppress the existing all-groups-failed guard.
This is not covered by the original topic-wide producer scan work (#2548) or
the consumer-offline
handling in #4002. Full-state Issue/PR searches found no implementation for
partial producer-group
scan failures.
## Reproduction
1. Query producer connections for a topic without specifying `producerGroup`.
2. Let active group A fail `examineProducerConnectionInfo`, while group B
returns normally.
3. The endpoint returns only B's connections with HTTP 200 and no indication
that A was omitted.
The same ambiguity starts one step earlier: active-group discovery skips an
unreachable Broker as
long as at least one other Broker responds, so groups registered only on the
failed Broker can be
silently absent too.
## Proposed design
Use strict completeness semantics for the topic-wide aggregate scan:
- Discover active producer groups in strict mode. If any Broker's producer
table cannot be read,
return HTTP 502 instead of scanning an incomplete group set.
- Query every discovered group. If any real group connection RPC fails,
return HTTP 502 instead of
returning a partial connection list.
- Keep a group-not-online response as a normal empty result; an inactive
group is not an RPC failure.
- Keep the explicit `producerGroup` query path unchanged.
- Keep the producer-group suggestion endpoint's existing best-effort
behavior; strictness applies
only where the API otherwise presents an aggregate inventory as complete.
This avoids an API schema change and reuses the existing frontend failure
path. A future endpoint can
add explicit partial-result metadata if retaining partial inventories
becomes a product requirement.
## Test plan
- A topic-wide scan fails when one Broker producer-table query fails and
another succeeds.
- A topic-wide scan fails when one producer-group connection query fails and
another succeeds.
- An offline producer group plus a successful group remains a successful
complete result.
- All-success, no-groups, explicit-group, and all-failed behavior remain
covered.
- Run focused Java 21 provider/service/controller tests, the full backend
suite/build/checkstyle,
frontend regression tests/build/lint, independent review, and `git diff
--check`.
--
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]
