unbridled-41 opened a new pull request, #4002:
URL: https://github.com/apache/rocketmq-dashboard/pull/4002
Fixes #TBD-ISSUE.
## Problem / Evidence
`GET /api/clients` fails with HTTP 502 "Failed to query consumer connections
from all groups" whenever every non-system consumer group of the instance is
offline — a completely normal state (consumer applications stopped, dev/test
cluster, nightly window) — instead of returning an empty connection list.
Because the consumer scan runs after the producer scan in the same request, the
producer connections already collected are discarded too.
The same misclassification hits the explicit producer-group lookup: `GET
/api/producer/connection?...&producerGroup=G` returns 502 "Failed to query
producer connections: Not found the producer group connection" when group `G`
has no online producers.
Client bytecode (rocketmq-tools 5.5.0, the version pinned by
`server/pom.xml`), verified via `javap -c` on `DefaultMQAdminExtImpl`:
- `examineConsumerConnectionInfo(String)`: when
`ConsumerConnection.getConnectionSet().isEmpty()` it throws `new
MQClientException(206, "Not found the consumer group connection")` (bytecode
offsets 90–126).
- `examineProducerConnectionInfo(String, String)`: throws `new
MQClientException("Not found the producer group connection", null)` for an
empty connection set.
`RocketMQClientProvider.findConsumerConnections`
(`server/src/main/java/org/apache/rocketmq/studio/provider/apache/RocketMQClientProvider.java:313-334`)
counts those per-group exceptions as scan failures, so "all groups offline" is
indistinguishable from "all brokers broken" and trips the guard at line 332.
The provider's own convention says normal "nothing here" states must be empty,
not 502 (existing comment at `:175-177` and the `isTopicNotExist` handling).
## Root cause / Fix
The all-failed heuristic (attempted > 0 && successful == 0 → 502) treats the
offline-group business answers as infrastructure failures. Fix:
- In the consumer scan, an `MQClientException` with response code 206 or
message "Not found the consumer group connection" counts as a *successful*
per-group query that found nothing, so an all-offline cluster yields an empty
list; groups with real failures keep the partial-results behavior, and a scan
where every group genuinely fails still returns 502.
- In the explicit producer-group query, the same offline-group message
returns an empty list alongside the existing missing-topic handling.
## Priority & scoring
PRIORITY 76 = impact 30 (the core Clients page errors out on a routine
cluster state and drops already-fetched producer data) + blast radius 14 (every
Apache-instance deployment; offline groups are routine) + reproducibility 18
(deterministic, one request, client behavior pinned by bytecode) + maintenance
value 14 (extends the established "normal absence → empty" convention already
accepted in this repo, e.g. NO_MESSAGE key queries and topic-route absence).
FIX_CONFIDENCE 95 (client exception contract verified against the exact
dependency version's bytecode; fix is a per-exception reclassification).
## Tests
`mvn -B -ntp test -Dtest='RocketMQClientProviderTest'`:
- Before the fix, the new regressions failed with the production errors:
`consumerScanTreatsOfflineGroupsAsEmptyInsteadOf502` → `BusinessException:
Failed to query consumer connections from all groups`;
`producerQueryWithExplicitOfflineGroupReturnsEmptyInsteadOf502` →
`BusinessException: Failed to query producer connections: Not found the
producer group connection`.
- After the fix: **Tests run: 27, Failures: 0, Errors: 0** (24 pre-existing
+ 3 new; `consumerScanFailsWhenEveryGroupConnectionQueryFails` still asserts
genuine failures → 502).
- Full backend suite (`mvn -B -ntp test`): **Tests run: 2038, Failures: 3**
— the 3 failures are the pristine-baseline set (AuthCorsIntegrationTest ×2,
AliyunInstanceProviderTest ×1, identical messages), i.e. zero new failures;
2035 baseline + 3 new tests.
## Risk
Low. Only the two specific offline-group answers are reclassified;
broker-unreachable failures, partial scans and the system-group short-circuit
keep their existing behavior. No API shape change — the response for this
normal state changes from an error to an empty list, matching the page's
contract.
--
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]
