zmuxuny opened a new issue, #7160: URL: https://github.com/apache/rocketmq-dashboard/issues/7160
### 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 rocketmq-studio at 127c47b06a268cc74224d5f34c56ec7c36ac0d55, built from source. The production source is unchanged while reproducing the defect. ### Runtime Environment Linux cloud development environment, React Testing Library + user-event in jsdom, using the actual Ant Design page and modal. This is a focused UI reproduction, not a live browser/backend or real notification send. ### Connected RocketMQ Cluster Not required: mocked delivery-page and retry services use the current API result shapes. No broker, MySQL, SMTP or webhook contacted. ### Build Toolchain Node.js 24.19.0; Vitest 4.1.10. Single default worker; existing cached dependencies. ### Describe the Bug The current-page bulk retry updates neither the visible delivery rows nor the selected-delivery fallback snapshot. If a successfully requeued delivery disappears from a FAILED-filtered reload, its open details fall back to the old FAILED row with the old attempt count/error and a retry action that the backend rejects. While the reload is pending, the old items row also masks the successful result. The actual reachable order is to start the bulk request first, then open the still-enabled row details before its response arrives. No click through an existing modal mask is needed. ### Steps to Reproduce 1. Open Notification Deliveries and select status FAILED, with failed deliveries 7 and 8 (attempt count 5). 2. Start Retry failed records on this page. Keep the bulk response pending. 3. While it is pending, use the enabled View delivery details action for delivery 7. 4. Complete the bulk call with succeededIds [7] and a failure for 8 (or success for both). 5. Complete the FAILED-filtered reload with only delivery 8, or an empty page if both succeeded. 6. Observe that delivery 7's dialog still renders FAILED, its old attempts/error and a retry button. The same old state is visible while the reload waits. ### What Did You Expect to See? Apply the confirmed bulk result to both current rows and the detail fallback for succeededIds only: PENDING, attempt count 0 and no last error. Preserve failed IDs and rejected-request state. A later authoritative list response should still take precedence over the optimistic result. ### What Did You See Instead? The successful delivery remains FAILED in the dialog even after it has left the FAILED-filtered list. After reload settles, retry becomes enabled again although retryFailedDelivery accepts only rows whose server status is FAILED. ### Additional Context Focused regression tests against unchanged production code: 2 failed / 3 controls passed. They cover a filtered-out successful row, partial success while reload is pending, partial/all-failure IDs, and a rejected bulk request. The interaction starts the bulk action before opening the modal and uses user-event's default pointer checks. This is a remaining boundary after merged #5665/#5664: that fix prefers refreshed items when the selected row is still present and patches the single-row retry path. A successful current-page bulk retry whose row no longer matches the filter does not update the fallback. It is not the duplicate-submission work in #2893, cross-page retry selection in #4384/#4055/#3782, or backend per-ID exception isolation in #5938. All-state targeted issue/PR searches did not identify another fix for this boundary. No production edits were made before filing this report. ### 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]
