zmuxuny opened a new issue, #5045: URL: https://github.com/apache/rocketmq-dashboard/issues/5045
### Before Creating the Bug Report - [x] I searched open issues and PRs; #4527 covers stale actions on ACL/alert pages while a request is loading, but not Notification Deliveries after a failed reload. - [x] This is a RocketMQ Studio defect. - [x] Reproduced against `rocketmq-studio` at `0228dad5b9c9460f3e18c5c3e2b56c6525856198`. ### Studio Version `rocketmq-studio` at `0228dad5b9c9460f3e18c5c3e2b56c6525856198`, built from source. ### Runtime Environment Any browser; this is the `web/src/pages/ops/notificationDeliveries.tsx` failure path. The regression can be reproduced in Vitest with a rejected list request. ### Connected RocketMQ Cluster Any instance/provider; the failing operation is the Studio notification outbox list API, before a cluster call. ### Describe the Bug The Notification Deliveries page keeps the previous page's `items` and `total` when `listAlertDeliveriesPage` fails. Its catch handler only shows a transient toast, then clears loading. If the operator switches from instance A to instance B (or from FAILED to DELIVERED) and the new list request fails, the old A/FAILED records appear under the new filter after the spinner disappears. Their detail and retry buttons remain enabled. Retrying one of these rows operates on the old delivery ID, despite the page indicating a different result set. ### Steps to Reproduce 1. Load Notification Deliveries with a FAILED record in the current filter. 2. Change the instance or status filter and make the subsequent list request reject (for example, a temporary backend/network failure). 3. Observe that the old row and its retry action remain visible under the new filter. Clicking retry submits the old row ID. ### What Did You Expect to See? A failed list request should leave a persistent error/retry affordance and should never present old rows as results for the newly selected filters or let the operator retry them from that view. ### What Did You See Instead? The page shows a brief error toast, then displays the previous result set with active actions and the new filter value. ### Additional Context The `.catch` branch in `notificationDeliveries.tsx` does not clear or invalidate the loaded page, while `.finally` sets `loading` to false. This differs from an actual empty response; the UI should make the failure explicit. A focused regression can reject the second list request after changing the status filter and assert that the old FAILED row cannot be retried and that a retry control reloads the current filter. ### Are You Willing to Submit a Pull Request? - [x] Yes. -- 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]
