iloveeyjafjalla opened a new issue, #6491: URL: https://github.com/apache/rocketmq-dashboard/issues/6491
### 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 (target branch) git commit id: 779b8c0e ### Runtime Environment OS: Windows 11 (10.0.26200) · Chrome, frontend dev server + Spring Boot backend on the local stack ### Connected RocketMQ Cluster RocketMQ version: 5.3.2 (apache/rocketmq nameserver + broker); not required to reproduce — the defect is client-side ### Build Toolchain JDK: 21.0.12.1+1 · Maven: 3.9.9 · Node: 20.19.5 ### Describe the Bug When the alert query fails (backend down, gateway error, request aborted), the System Alerts page (`ops/system-alerts`) keeps presenting the feed as if it had been read successfully and were empty: - the header subtitle still claims `本页 0 条未确认` / `0 unacknowledged on this page`, because `unackCount` is computed from the empty `alerts` array (`web/src/pages/ops/systemAlerts.tsx:243`, subtitle at `:481`); - the per-level chips render counts derived from that same empty array (`:526`); - the only signal is a transient toast (`message.error(t('sysAlerts.loadFailed'))` at `:216`), which disappears and leaves nothing on the page. An operator who misses the toast reads the page as "no unacknowledged alerts" — the opposite of a failed read — and the page offers no way to retry except changing a filter. ### Steps to Reproduce 1. Start RocketMQ Studio and open the System Alerts page (`ops/system-alerts`). 2. Make the alert query fail — for example stop the backend (or let the gateway refuse the request) and then reload, or change a filter/page so the list effect refetches. 3. The page keeps claiming "本页 0 条未确认" / "0 unacknowledged on this page" and shows the empty feed state, while the failure only appears as a toast. No retry control appears. Deterministic check used for the fix: `web/src/pages/ops/__tests__/SystemAlertsPage.test.tsx` with `listSystemAlertsPage` rejecting the first call. On the current target branch the new case fails with `Unable to find an element with the text: 获取数据失败`; with the fix it passes and the retry recovers the feed. ### What Did You Expect to See? A failed read should stay visible on the page and must not be rendered as a measured result: - the header must not assert a count it never read; - the page should surface the failure and offer a retry that re-runs the query in place. ### What Did You See Instead? Found while reviewing the failure states of the ops pages. Sibling fixes already landed or are in review for the same class: the instance-list failure state (#6348), the audit page (#6485), and `fix(alerts): stop reporting a failed silence read as no maintenance windows` (#6127) for the maintenance-windows dialog of this same page — that one covers the dialog, not this feed. Failure path on 779b8c0e: list effect at `web/src/pages/ops/systemAlerts.tsx:204-216`; `getCollectorStatus` tolerates its own failure separately. I plan to submit a fix with a regression test. Drafted with AI assistance; the analysis and this text were reviewed before posting. ### Additional Context _No response_ ### 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]
