Frun1na opened a new issue, #5664: URL: https://github.com/apache/rocketmq-dashboard/issues/5664
### 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` git commit id: `6a68042f` deployed as: built from source ### Runtime Environment OS: Ubuntu 22.04 (WSL2) MySQL: not applicable — the defect is in the page's drawer state browser: any (pinned by the page's own component test) ### Connected RocketMQ Cluster RocketMQ version: not applicable — the page reads delivery rows from the Studio database access mode: not applicable deployment: not applicable ### Describe the Bug The notification-delivery detail drawer renders a snapshot taken when it was opened, and only the single-row retry keeps that snapshot in step. Queuing the same delivery from anywhere else leaves the drawer on the stale row: - `retryVisibleFailures` ("Retry failed records on this page") calls `retryAlertDeliveries(ids)` and then `refresh()`. `refresh` bumps a nonce and the list effect replaces `items`, but `selectedDelivery` is never updated. - the same happens when another operator retries the delivery, or when the retried row comes back with a different `attemptCount` / cleared `nextAttemptAt` / cleared `lastError`: the drawer reports "the details the previous page snapshot had", not the current row — and the row's status in the drawer is what enables the retry button inside it. The consequence is an action the backend rejects on purpose: pressing the drawer's retry while the delivery has already been queued sends a retry for a non-FAILED row, and `NotificationOutboxService` answers `400 Only failed notification deliveries can be retried` (the same guard also covers the lost-update race). The operator sees a red failure toast for an action that had already succeeded a moment earlier. Single-row retry (`retryDelivery`) patches the drawer optimistically, which is why this only shows up through the bulk path or through a second operator. ### Steps to Reproduce 1. Open the Ops → notification deliveries page and filter to a failed delivery. 2. Open that delivery's detail drawer (the eye action) — it shows `FAILED` and a retry button. 3. Without closing the drawer, press "Retry failed records on this page". 4. The list reloads and the row becomes `PENDING`, but the drawer still shows `FAILED`. 5. Press the drawer's retry: the request fails with `400 Only failed notification deliveries can be retried`, and the drawer keeps showing the pre-retry state, including a stale `lastError`. ### What Did You Expect to See? The open drawer should keep showing the delivery the list currently reports — `PENDING` after a successful retry, with the retry button gone — so its content never contradicts the table behind it. ### What Did You See Instead? A drawer frozen at the state it was opened with: `FAILED`, the old attempt count, the old error, and a retry button that can only fail. ### Additional Context - the snapshot is still the right fallback for a row the current page no longer carries (for example after the filters change while the drawer is open). - the page's own test suite covers the single-row path only, so the bulk path had no coverage. ### 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]
