Frun1na opened a new issue, #4699: URL: https://github.com/apache/rocketmq-dashboard/issues/4699
### Before Creating the Bug Report - [x] I have searched the [open issues](https://github.com/apache/rocketmq-dashboard/issues) of this repository and believe that this is not a duplicate. - [x] This is a defect in RocketMQ Studio, not a usage question and not a defect in another Apache RocketMQ repository. - [x] I can reproduce this on the current `master` branch, or I have stated the exact version I am running below. ### Studio Version branch: rocketmq-studio git commit id: 7ce9a68215c4cd1c7025013d02135b43b6aa6ba1 deployed as: built from source (`cd web && npm ci && npm run build`) ### Runtime Environment OS: Windows 11 with WSL2 (Ubuntu 24.04.3 LTS) MySQL: 8.0.36, container from `deploy/docker-compose.yml` browser: Chrome 141 ### Connected RocketMQ Cluster Any registered instance; reproduced by making the Ops home request fail (backend unreachable / 5xx), and in Vitest with a rejected `queryOpsHomePage`. ### Build Toolchain Node.js 20.19.0, npm 10.8.2 ### Describe the Bug `web/src/pages/studio/Ops.tsx` derives every banner and every write control from a single boolean, `configurationAvailable`. It is initialised to `false`, set from the response, and left at `false` by the load's `catch` — which only raises a toast. The render condition is `!configurationAvailable`, so a failed load renders the "not supported" banner, whose message is "运行时配置不可用" and whose description falls back to "当前集群不支持读取或更新 Ops 配置。". That is a claim the page cannot make: it does not know whether the cluster supports the configuration, only that the request failed. The same boolean also disables `writeOperationEnabled`, so every write control disappears behind a reason that is not true. Nothing on screen offers a retry, and the toast is gone after a few seconds. The same condition makes the banner appear on first paint, before the request has answered. ### Steps to Reproduce 1. Open the Ops page while `GET /api/ops/home` fails (stop the backend, or make it return 5xx). 2. Read the banner at the top of the page. ### What Did You Expect to See A failure state that says the configuration could not be loaded, with a way to retry it, distinct from the state that means the cluster genuinely does not expose the Ops configuration. While the request is still in flight, no claim either way. ### What Did You See Instead "运行时配置不可用 — 当前集群不支持读取或更新 Ops 配置。", with all write controls hidden and no retry. On a slow but working backend, the same banner flashes before the response arrives. ### Additional Context I have a fix ready: PR #4698. ### Are You Willing to Submit a Pull Request? - [x] Yes, I am willing to submit a pull request. -- 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]
