unbridled-41 opened a new issue, #4967: URL: https://github.com/apache/rocketmq-dashboard/issues/4967
### 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. Searched for `instance list load failure`, `instances request failed page empty`, `instance filter unavailable`, `实例列表加载失败`, `useInstanceFilter` and `empty instance page`. Two issues cover the **same class on other surfaces** and are the reason this one is scoped to the instance pages — see "Boundary" below; neither covers `useInstanceFilter` or these five pages. - [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: `1ef5d860` (the revision this was written against; the fix is in PR #4953, branched from that commit) deployed as: not required for the reproduction — see Runtime Environment. ### Runtime Environment Reproduced with the frontend unit tests (`cd web && npx vitest run src/pages/instance/__tests__/DLQPage.test.tsx -t "says so when the instance list itself failed to load"`), which need no browser and no cluster. In a running console any failure of `GET /instances` (service restarting, reverse-proxy error, 500) triggers it. ### Connected RocketMQ Cluster Not involved. The failing request is Studio's own `GET /instances`; the pages' own data requests are never issued in this state. ### Describe the Bug When the instance list cannot be loaded, every instance-scoped page renders an **empty result**: the table is cleared, the total goes to zero ("共 0 个 Topic" / "共 0 个 Group"), and no error and no retry is offered. That is indistinguishable from an instance that genuinely has nothing, and the page's own data requests were never sent. The pages have nothing to fall back on: the instance-scoped endpoints require an `instanceId` (`MetadataService.normalizeInstanceId`, `listTopicsPage`, `listConsumerGroupPage`, …), so "no instance selected" is not a working state. The shared hook swallows the failure and then reports the absence as a selection: * `web/src/hooks/useInstanceFilter.ts:76-78` — `.catch(() => { /* 实例列表加载失败时不做实例过滤，保持页面数据可用 */ })`, and `:87-90` derives `selectedInstanceId` from the resulting empty `instances` array, so it is `undefined`. The hook's return value carries only `instancesLoading`, so a caller cannot tell "the list came back empty" from "the list never came back". * `web/src/pages/instance/topic.tsx:474-481` — the page then clears everything and stops loading (`setTopics([]); setTotalTopics(0); …; setLoading(instancesLoading)`), with `loadTopicPage` bailing at `:439`. * `consumer.tsx:381-390` does the same; `dlq.tsx:188-199` bails out of its group effect with `loading = false` and leaves the initial empty rows and `total = 0` on screen. * The other two pages show their own version of it: `acl.tsx:128` derives `hasSelectedInstance` from the missing id so its rules and users tabs stay empty under a zero-count subtitle, and `message.tsx:493-497` shows `messagePage.selectInstanceBeforeQuery` — a hint that asks the user to pick an instance from a list that could not be loaded. ### Steps to Reproduce 1. `cd web && npx vitest run src/pages/instance/__tests__/DLQPage.test.tsx -t "says so when the instance list itself failed to load"` on `1ef5d860`. 2. The test rejects `listInstances()` and renders the page. 3. The run fails: no element with the text 实例列表加载失败 and no retry control. In a running console: open `/instance/<id>/topic` (or consumer, message, acl, dlq) while `GET /instances` fails; the page shows a zero total and an empty table with no explanation. ### What Did You Expect to See? A failed load and an empty result must look different. When the instance list cannot be loaded, the page should say so and offer a retry, in the same way the deliveries page already does for its own instance filter (`deliveries.instancesLoadFailed`, added with #4700). ### What Did You See Instead? Five pages present the failure as an empty instance: cleared rows, a zero total, no error and no way back other than a manual reload. ### Additional Context **Boundary.** Two issues track the same class on other surfaces, which is why this one is scoped to `useInstanceFilter` and the five instance pages rather than restated generally: * #4612 (open) — failed *registry* loads silently emptying the cluster page's tables. * #4701 (closed, fixed by #4700) — the notification-deliveries page's instance filter failing silently and without retry. That fix was applied to that one page and left the shared hook, and therefore these five pages, untouched. They are siblings, not duplicates: different loaders, different pages, different fixes. If the maintainers would rather see them folded together, this issue can be closed in favour of #4612 — say so and I will not pursue it separately. Corresponding pull request: #4953 (`fix(web): tell a failed instance-list load apart from an empty instance`), which exposes the failure and a retry from the hook and surfaces them in the shared instance selector used by all five pages. ### 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]
