unbridled-41 opened a new issue, #4609:
URL: https://github.com/apache/rocketmq-dashboard/issues/4609
### Studio Version
branch: master
git commit id: d50ffecc9d7e8f8f46da64198831bd7952e6974e
### Problem
Both config-diff modals on the cluster page (`NameServer 管理` and `Broker`
tabs) render a permanent "加载中" info banner when the diff request fails.
`openNameServerConfigDiff` / `openBrokerConfigDiff`
(`web/src/pages/cluster/index.tsx:373-425`, base d50ffecc) catch a failed
request by only resetting `loading: false`; the state keeps `result: null`. The
modal render branches (`:960`, `:1120`) show the diff content when `result` is
truthy and otherwise fall through to:
```
<Alert showIcon type="info" message={t('cluster.nsConfigDiffLoading')} />
```
So after a failure the spinner stops but the body keeps showing the
"loading" info alert forever — no error state, no retry path. The
`message.error` toast disappears after a few seconds; the modal is left in a
misleading state.
This is a separate defect from #3292/#4165 (stale-response request guards on
the same modals): the guards fix racing responses, this is the failure path
rendering.
### Evidence
- `web/src/pages/cluster/index.tsx:391-395` (NameServer catch):
`setNsConfigDiffState((current) => ({ ...current, loading: false }));` —
`result` stays `null`.
- `web/src/pages/cluster/index.tsx:418-422` (Broker catch): same shape.
- `web/src/pages/cluster/index.tsx:960` / `:1120`: `result ? (diff tables) :
<Alert type="info" message=loading />` — there is no third "failed" branch.
- Trigger: click 配置对比 on a cluster whose NameServer/Broker is unreachable
(the most common failure for a diff call, which connects to the node directly)
→ the request 502s → modal shows the loading banner indefinitely.
### Impact
- The operator cannot tell "still loading" from "failed" — the most common
real-world failure (node unreachable) renders exactly like an in-flight request.
- The only escape is closing the modal and re-opening it; no retry
affordance.
### Expected behavior
A failed diff request renders an error alert (with a retry action) instead
of the loading info banner; the loading banner only shows while a request is
actually in flight.
### Related work
- #3292 / PR #4559-family and #4165 / PR #4166: stale-response request
guards on these same two modals (different defect — race handling, not the
failure path).
- #2915 (closed): per-broker failure details inside the diff result — also
different: that covers partial failures in a 200 response.
### 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]
