btlqql opened a new issue, #1040:
URL: https://github.com/apache/rocketmq-dashboard/issues/1040
## Problem
`RocketMQDashboardProvider` reads the live NameServer topology without
guarding the fields that come back from the wire:
- `clusterInfo.getClusterAddrTable()` / `getBrokerAddrTable()` are
dereferenced directly (`.size()`, `.values()`) — a JSON payload missing either
map is `null` and throws NPE.
- `brokerData.getBrokerAddrs().get(0L)` is called without a null check — a
broker registered without an address table (e.g. mid-registration) throws NPE.
The whole computation sits inside one outer `try`, so any single NPE falls
into `catch (Exception e) { return emptyDashboard(); }` and **every number on
the dashboard is silently zeroed** — cluster count, broker count, topic count,
group count and TPS all become 0, masking the data that could have been
collected.
Sibling providers already defend these exact fields: `RealClusterProvider`
defaults the maps to `Map.of()`, and `RocketMQClusterProvider` null-checks
`getBrokerAddrs()` before use. `RocketMQDashboardProvider` is the remaining one
that does not.
## Expected
The dashboard survives a partial/absent NameServer topology: each stats
block that can fail independently degrades on its own instead of zeroing the
whole page.
## Acceptance criteria
- `getClusterAddrTable()` / `getBrokerAddrTable()` null are handled (treated
as empty) without NPE.
- A broker with a null/empty `getBrokerAddrs()` is skipped instead of
throwing.
- A single failing stats block does not zero unrelated blocks.
- Unit tests cover the null-topology and null-addr-table paths.
--
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]
