zmuxuny opened a new issue, #6356: URL: https://github.com/apache/rocketmq-dashboard/issues/6356
### 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`, commit `779b8c0e7aed2396d3cc72743dcd544ea48e9ae6`. Reproduced from source in a focused frontend component test, not a live deployment. ### Runtime Environment Linux cloud workspace; Node.js 24.19.0; repository-pinned Vitest 4.1.10, React 18 and Ant Design 5; jsdom. MySQL and a live browser are not required for this reproduction. ### Connected RocketMQ Cluster No live cluster was used. Ordinary API/service boundaries return controlled responses; the actual page, modal/drawer, filters and pagination are rendered. No real credentials or customer data were used. ### Build Toolchain _No response_ ### Describe the Bug A temporary failure of `GET /liteTopic/capability` is rendered as “Current cluster does not support LiteTopic; upgrade to RocketMQ 5.x.” That is a capability claim the failed request cannot support. The branch also removes the page's Refresh button and provides no retry, so a transient timeout leaves a supported cluster unusable in the current page. Failing closed is correct: list/quota and mutation controls must remain unavailable while support is unverified. The missing behavior is an explicit probe-failure state and a way to retry the probe. ### Steps to Reproduce 1. Open LiteTopic for a supported deployment. 2. Make its capability request reject once with a timeout/network failure. 3. Restore connectivity. 4. Observe the displayed explanation and try to retry without leaving/reloading the page. ### What Did You Expect to See? A capability-check failure with Retry. While retrying, the page stays fail-closed. If the next response is `supported: true`, load the inventory normally; if it is `supported: false`, retain the genuine unsupported state. ### What Did You See Instead? The UI recommends a broker upgrade and exposes no retry action. The capability effect runs only on mount, so network recovery alone cannot restore the page. ### Additional Context ### Evidence - [Capability effect](https://github.com/apache/rocketmq-dashboard/blob/779b8c0e7aed2396d3cc72743dcd544ea48e9ae6/web/src/pages/studio/LiteTopic.tsx#L229-L265): the rejection branch writes `setCapabilitySupported(false)`, the same value as a successful unsupported response. - [Unsupported rendering](https://github.com/apache/rocketmq-dashboard/blob/779b8c0e7aed2396d3cc72743dcd544ea48e9ae6/web/src/pages/studio/LiteTopic.tsx#L791-L808) returns only an informational alert. The Refresh action is below that return and unreachable. A new real-component regression rejects the first probe, prepares `supported: true` for a second probe, and expects a fail-closed Retry path to recover and render the real list. On unchanged production it fails at the missing Retry button; the DOM contains the unsupported/upgrade alert. The existing fail-closed expectation is retained in the proposed behavior, not relaxed. ### Related Work / Scope - [#801](https://github.com/apache/rocketmq-dashboard/pull/801), consolidated in merged [#932](https://github.com/apache/rocketmq-dashboard/pull/932), correctly stopped assuming support after a failed probe. Both diffs were inspected. This report preserves that safety behavior and adds truthful error/recovery handling. - [#4568](https://github.com/apache/rocketmq-dashboard/pull/4568) concerns probing all broker masters on the backend. - [#6117](https://github.com/apache/rocketmq-dashboard/pull/6117) concerns an individual session-detail request, not the capability gate. No backend/provider support semantics or capability privileges need to change. ### Verification Scope Red-only reproductions on unchanged production: `npm test -- --maxWorkers=1 src/pages/instance/__tests__/InstancePage.test.tsx src/pages/instance/__tests__/DLQPage.test.tsx src/pages/studio/__tests__/LiteTopic.test.tsx -t 'Test$'` ran the three new cases: three expected assertion failures, 74 existing cases skipped. This is not a full-suite or real-broker result. Production has not been changed yet. ### 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]
