Frun1na opened a new issue, #6077: URL: https://github.com/apache/rocketmq-dashboard/issues/6077
### 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 `rocketmq-studio` branch, or I have stated the exact version I am running below. ### Studio Version branch: `rocketmq-studio` git commit id: `5e4c39b0` deployed as: reproduced by unit tests against that commit (the affected code is the web client) ### Runtime Environment OS: Ubuntu on WSL2 MySQL: not applicable — the defect is in the web client's rendering of a failed instance-list request browser: not applicable — reproduced in a jsdom unit test (vitest + Testing Library) ### Connected RocketMQ Cluster RocketMQ version: not applicable — reproduced with a stubbed `/api/instances` call in a unit test access mode: not applicable deployment: not applicable ### Describe the Bug Four console pages treat a failed instance-list request as "this deployment has no instances". Each loads the list with a `catch` that only clears the options, so the failure has no state and no user-visible trace: - `web/src/pages/home/dashboard.tsx:110` — the instance filter in the dashboard header - `web/src/pages/settings/DataSourceTab.tsx:201` — the "Applicable instances" picker in the data-source dialog - `web/src/pages/studio/Producer.tsx:114` — the instance filter on the producer-connections page - `web/src/pages/studio/LiteTopic.tsx:333` — the instance picker in the extend-TTL dialog For example, the dashboard loads the list (base `5e4c39b0`): ```ts void listInstances() .then((nextInstances) => { if (!cancelled) setInstances(nextInstances.filter(supportsApacheRuntime)); }) .catch(() => { if (!cancelled) setInstances([]); }); ``` The Select therefore renders with no options, no error status and no retry, which reads as "there are no instances" — a conclusion a failed request cannot support. On the producer page it is worse: `Search` stays disabled because no instance is ever selected. In the LiteTopic dialog, confirming the form then returns early (`handleExtendTTL` bails out when `extendTTLForm.instanceId` is empty) without telling the user anything. The same shape was already fixed twice: #4700 (`71ffb696`) gave the notification-deliveries instance filter an error state and a retry and named `home/dashboard.tsx` and `settings/DataSourceTab.tsx` as still silently clearing their lists; #4953 (`79962a4f`) did it for the instance-scoped pages through the shared `InstanceSelect`. The remaining `listInstances()` call sites report the failure (`pages/ops/alerts.tsx`, `pages/studio/BrokerCluster.tsx`, `pages/cluster/index.tsx`, `pages/instance/index.tsx`) or retry (`web/src/hooks/useInstanceFilter.ts`), so these four are the ones left. ### Steps to Reproduce Reproduced by a unit test rather than against a cluster; the request stub is the only setup needed: 1. Render `DashboardPage` with `listInstances` rejecting (equivalently: open the console while `GET /api/instances` fails). 2. Look at the instance filter in the page header. 3. The Select is empty, there is no message, and there is no way to retry. The same three steps against `DataSourceTab` (open "Add data source"), `ProducerPage` and the LiteTopic "Extend TTL" dialog show the same empty control. ### What Did You Expect to See? The page should say that the instance list could not be loaded and offer a retry, instead of presenting an empty list as a fact. The four pages already have the copy for it (`instance.listLoadFailed` / `common.retry`), used by the shared `InstanceSelect` on the instance pages. ### What Did You See Instead? An empty instance Select on all four pages, with no error message and no retry. On the producer page the `Search` button also stays disabled, and in the LiteTopic dialog the confirm button does nothing silently. ### Additional Context - A fix with a regression test for each of the four pages follows in a pull request. - The four failures are pinned by unit tests that fail on `5e4c39b0` and pass with the fix. ### 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]
