unbridled-41 opened a new pull request, #4568:
URL: https://github.com/apache/rocketmq-dashboard/pull/4568
Fixes #4567.
## Problem / Evidence
`RocketMQLiteTopicProvider.isSupported()` probes only the first master
returned by `examineBrokerClusterInfo` (`masters.get(0)`, master `d50ffecc`
:112). If that single master runs a pre-lite build (rolling upgrade /
mixed-version cluster) or is momentarily unreachable, the probe fails and the
console reports the LiteTopic capability as unsupported for the **whole
cluster**, even though every other master fully answers the lite admin RPC.
Because the enumeration order is arbitrary from the operator's point of view,
this is a single point of failure for the capability signal — and a transient
failure of exactly one broker flips the page off with no retry.
Red (new regression, master + test): two masters, `getBrokerLiteInfo(m1)`
throws and `getBrokerLiteInfo(m2)` returns a body → `isSupported()` returns
`false` (`Expecting value to be true but was false`).
## Root cause / Fix
Probe every master and report supported when any of them answers; a
per-master probe failure only excludes that master (debug-logged), mirroring
the per-master degradation every read path in the same file already applies and
matching the cluster-wide semantics of the list page itself.
- `RocketMQLiteTopicProvider.java`: +16/−2 (`isSupported` loop over all
masters).
- `RocketMQLiteTopicProviderTest.java`: +10/−0
(`isSupportedIsTrueWhenAnyOtherMasterAnswersTheLiteProbe`).
## Priority & scoring
PRIORITY 72 = impact 28 (the capability gate disables the entire LiteTopic
page cluster-wide on an ordinary ops event — mixed-version upgrade or one
broker restarting) + scope 12 (single method, no callers beyond the capability
endpoint) + reproducibility 18 (deterministic two-master unit repro) +
maintenance value 14 (closes the last single-master assumption in the provider;
the read-path twin is #4565). FIX_CONFIDENCE 96: stateless loop, one
deterministic regression, no API change.
## Tests
- `mvn -o test -Dtest=RocketMQLiteTopicProviderTest`
- Red (fix stashed, new test kept): `Tests run: 15, Failures: 1` —
`isSupportedIsTrueWhenAnyOtherMasterAnswersTheLiteProbe` expected `true` but
was `false`.
- Green: **15/15 passed, 0 failures, 0 errors**; `mvn -o checkstyle:check`
→ 0 violations, BUILD SUCCESS.
- Full backend suite (`SPRING_PROFILES_ACTIVE=dev mvn -o clean test`, this
exact tree): **2415 tests, 0 failures** (`Tests run: 2415, Failures: 0, Errors:
0, Skipped: 0`, BUILD SUCCESS). Pristine `origin/master` `d50ffecc` measured on
the identical XML basis in a clean worktree: **2414 tests, 0 failures** — the
+1 delta is exactly the new regression test.
## Risk
Low. One-sided improvement: `isSupported()` can only return `true` more
often (when a non-first master supports lite); `false` results are unchanged
for clusters where no master answers. The page's read paths still degrade per
master as of #4566, so a `true` probe with some failing masters renders partial
data rather than failing.
Upstream CI note: the repository's CI workflow fails at startup for every
branch and PR (infrastructure-level, also on maintainer branches), so local
verification above substitutes for 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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
