You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@rocketmq.apache.org by "unbridled-41 (via GitHub)" <gi...@apache.org> on 2026/09/20 02:37:55 UTC
[I] [Studio][Bug] LiteTopic capability probe checks only the first master and disables the page on mixed clusters [rocketmq-dashboard]
unbridled-41 opened a new issue, #4567:
URL: https://github.com/apache/rocketmq-dashboard/issues/4567
## Problem
`RocketMQLiteTopicProvider.isSupported()` probes only the first broker master returned by `examineBrokerClusterInfo`:
```java
List<String> masters = masterAddresses(admin);
return !masters.isEmpty() && admin.getBrokerLiteInfo(masters.get(0)) != null;
```
If that single master runs a pre-lite build (mixed-version cluster / rolling upgrade) or is momentarily unreachable, `getBrokerLiteInfo(masters.get(0))` throws, the exception is swallowed, and the console reports `{"supported": false}` — even when every other master in the cluster fully supports the lite admin RPC. The LiteTopic page then degrades to "not supported" for the whole cluster, and a transient failure of exactly one broker (the one that happens to be enumerated first) flips the capability off with no retry.
The iteration order of `examineBrokerClusterInfo` is arbitrary from the operator's point of view, so this is a single point of failure for the capability signal.
## Evidence
- `server/src/main/java/org/apache/rocketmq/studio/provider/apache/RocketMQLiteTopicProvider.java:110-113` @ master `d50ffecc` — probe reads `masters.get(0)` only.
- Repro (unit level, two masters): `getBrokerLiteInfo(m1)` throws, `getBrokerLiteInfo(m2)` returns a body → `isSupported()` currently returns `false` although m2 answers.
## Expected behavior
Probe the masters and report supported when any of them answers the lite admin RPC; a per-master probe failure just excludes that master. This matches the same file's per-master degradation on every read path and the console's cluster-wide semantics (the list page itself aggregates across masters).
## Related work
- #4565 / fix PR (open, same file): one failing master fails the list/quota pages — the same single-master assumption on the read paths; this issue is its capability-probe counterpart.
- PR #4562 (open, same file): per-master backlog aggregation in `buildSummary`.
## 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: commits-unsubscribe@rocketmq.apache.org.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [Studio][Bug] LiteTopic capability probe checks only the first master and disables the page on mixed clusters [rocketmq-dashboard]
Posted by "lizhimins (via GitHub)" <gi...@apache.org>.
lizhimins commented on issue #4567:
URL: https://github.com/apache/rocketmq-dashboard/issues/4567#issuecomment-5845585583
Fixed in c6c722ac5 (#4568) on the `rocketmq-studio` branch.
Closing manually: GitHub only auto-closes an issue when the pull request is merged into the repository's default branch, and `rocketmq-studio` is not it.
--
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: commits-unsubscribe@rocketmq.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [Studio][Bug] LiteTopic capability probe checks only the first master and disables the page on mixed clusters [rocketmq-dashboard]
Posted by "RockteMQ-AI (via GitHub)" <gi...@apache.org>.
RockteMQ-AI commented on issue #4567:
URL: https://github.com/apache/rocketmq-dashboard/issues/4567#issuecomment-5747209246
**Issue Evaluation**
Category: `bug` | Status: **Confirmed**
The single-master probe in `RocketMQLiteTopicProvider.isSupported()` is a legitimate availability issue. Checking only `masters.get(0)` means a transient failure or version mismatch on that one broker disables the entire LiteTopic feature for the cluster.
**Root Cause:** No iteration or fallback when the first master is unreachable or pre-lite; exception is swallowed and capability is reported as false.
**Impact:** Mixed-version clusters or rolling upgrades incorrectly report LiteTopic as unsupported; transient broker failures cause feature degradation.
**Severity:** High (feature availability in production clusters)
Fix PR #4568 is already submitted. The issue includes clear code references and impact analysis.
---
*Automated evaluation by RockteMQ-AI*
--
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: commits-unsubscribe@rocketmq.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [Studio][Bug] LiteTopic capability probe checks only the first master and disables the page on mixed clusters [rocketmq-dashboard]
Posted by "lizhimins (via GitHub)" <gi...@apache.org>.
lizhimins closed issue #4567: [Studio][Bug] LiteTopic capability probe checks only the first master and disables the page on mixed clusters
URL: https://github.com/apache/rocketmq-dashboard/issues/4567
--
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: commits-unsubscribe@rocketmq.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org