unbridled-41 opened a new issue, #4565:
URL: https://github.com/apache/rocketmq-dashboard/issues/4565
## Problem
The Apache LiteTopic list and quota pages fail completely (HTTP 502) when a
single broker master fails its `getBrokerLiteInfo` call, even though every
other master in the cluster answers normally.
`discoverParentTopics` and the quota loop call
`admin.getBrokerLiteInfo(master)` without the per-master try/catch that guards
every other per-master read in the same file (`getParentTopicInfo`,
`getLiteGroupInfo`, `getLiteClientInfo`, `examineConsumerConnectionInfo`,
`getBrokerConfig`, `examineTopicConfig`). Any exception thrown for one master
propagates out of the admin action, which `MqAdminExtFactory.execute` converts
into `BusinessException(502, "RocketMQ admin call failed: …")` for the whole
request.
Reaching the code only requires one of these ordinary conditions:
1. A rolling upgrade / mixed-version cluster: one master runs a build
without the lite admin RPC and answers with an unsupported-code error (an
`MQBrokerException`), while master[0] (which the capability probe checks)
supports it — so `isSupported()` returns `true` and the console enters the
LiteTopic page straight into the 502.
2. One master is restarting or unreachable from the dashboard while the
others are fine.
## Evidence
-
`server/src/main/java/org/apache/rocketmq/studio/provider/apache/RocketMQLiteTopicProvider.java`
@ master `d50ffecc`:
- `discoverParentTopics` (:159): `GetBrokerLiteInfoResponseBody info =
admin.getBrokerLiteInfo(master);` — uncaught inside the per-master loop of
`listLiteTopics`.
- `getQuota` loop (:394): the same uncaught call.
- Contrast: `liteTopicConfig` (:369), `groupLag` (:524),
`clientLastAccess`, `brokerConfig` (:428), `consumerConnections` all catch
per-master and continue.
- Regression added in the linked PR: two masters, `getBrokerLiteInfo(m2)`
throws → `listLiteTopics`/`getQuota` currently propagate (`IllegalState broker
restarting` escapes the action), while m1's data was fully available.
## Impact
One degraded broker takes down the entire LiteTopic inventory and quota
cards for the whole cluster — an availability blip on one broker is amplified
into a console-wide outage of the feature, exactly the failure mode the sibling
providers (e.g. `RocketMQClientProvider`, `RocketMQMessageProvider`) already
grade to empty/partial results.
## Expected behavior
A master that fails its `getBrokerLiteInfo` call is skipped (warn-logged),
and the page renders the aggregated data from the masters that answered. If no
master answers, the existing empty/503 semantics still apply.
## Related work
- #4562 (open PR, same file): fixes the summary single-master read in
`buildSummary` (different defect, disjoint hunk).
- #4535 / PR #4536 (open): session-detail read failures are surfaced instead
of rendered as zero (session path only; list/quota loops untouched).
## PR
Fix incoming.
--
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]
