zmuxuny opened a new issue, #5554: URL: https://github.com/apache/rocketmq-dashboard/issues/5554
### 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 Originally reproduced on `rocketmq-studio@0228dad5b9c9460f3e18c5c3e2b56c6525856198`, built from source, and reported on 2026-09-23. Current fix PR #5048 records fresh 2026-10-04 validation against `rocketmq-studio@6a68042fa73a513f40436ca721944b4de48181ec`. ### 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. ### Build Toolchain _No response_ ### 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. 4. For the pending-request boundary covered by #5048, keep the replacement request unresolved and verify that old row actions cannot be used while the new filter is displayed. ### 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. Old row actions should be disabled while the replacement request is pending; after failure, stale rows, totals and open detail should be cleared. The retry must reload the current filters. ### 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 ### Previous report and current fix (2026-10-04) This replaces [#5045](https://github.com/apache/rocketmq-dashboard/issues/5045), automatically closed by `github-actions[bot]` for inactivity on 2026-10-04. The closure was a stale-workflow action, not a maintainer rejection of the reported defect. The existing fix PR is [#5048](https://github.com/apache/rocketmq-dashboard/pull/5048), which remains open. October 4 validation, dated CI results, and remaining limitations are recorded there. Overall CI is not green. ### Historical verification (2026-09-26) The September 26 report recorded 5/5 focused frontend tests passing and a separate combined check with #5034. These results are historical. Current October 4 validation and CI limitations are preserved in #5048. ### Report history and related work The original #5045 was filed on 2026-09-23, and its fix PR #5048 remains open. Related [#5494](https://github.com/apache/rocketmq-dashboard/issues/5494), filed on 2026-10-03, collects failed-filtered-reload stale rows across ten pages, including Notification Deliveries. This focused replacement preserves the earlier report and the existing PR association. Its scope includes disabling stale actions while loading, clearing stale rows and open detail on failure/filter change, and persistent retry with the current filters. #5048 does not address all ten pages in #5494. 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 regression rejects the second list request after changing the status filter, asserts that the old FAILED row cannot be retried, and checks that retry reloads the current filter. #4527 concerns stale actions on ACL/alert pages while loading. #5367 concerns overlapping per-alert delivery-detail refreshes on System Alerts, a different page and sequence. ### 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]
