zmuxuny opened a new issue, #4486: URL: https://github.com/apache/rocketmq-dashboard/issues/4486
## Problem The DLQ detail resend flow can publish a refresh from an old instance after the operator has already switched to another instance and opened another group's message drawer. `resendSelectedMessages` starts with the current `selectedInstanceId` / `detailGroup`, awaits `resendDLQSelected`, then unconditionally calls `loadDetailMessages(detailGroup, detailPage, detailPageSize)`. That async continuation retains the old render's instance/group. `loadDetailMessages` increments the shared `detailRequestIdRef`, so the old-instance refresh can supersede a newer detail request from the newly selected instance. ## Deterministic reproduction 1. On instance A, open DLQ group A and select a message. 2. Start `resendDLQSelected` and keep the request pending. 3. Switch to instance B and open DLQ group B. Keep B's detail request pending. 4. Resolve A's resend successfully. Its continuation starts another A detail load and advances `detailRequestIdRef`. 5. Resolve B's original detail request. On current `master` (`987b748e8f4f421c5cd3c4c4e51a064cc7e59f18`), B's response is discarded as stale while the old A refresh can populate the drawer. A red-first Vitest regression fails because `instance-b-message` never appears after this interleaving. ## Impact This is more than stale presentation. Once old-instance rows are rendered inside the new instance/group drawer, selecting them and using the current resend action can submit those message ids with the new instance/group context. At minimum operators see the wrong DLQ inventory; at worst a follow-up mutation is formed from mismatched resource identities. The old in-flight resend also keeps the page-wide `resendInFlightRef` set after the instance switch, temporarily blocking legitimate resends in the new scope. ## Expected behavior - Instance/scope changes invalidate in-flight detail loads and resend UI continuations. - Completion of an old resend must not refresh, clear selection, toast, set errors, or release loading state in a newer scope. - A new instance is not blocked by an old scope's UI in-flight guard. - If the user remains in the same scope, a successful resend still refreshes the current detail page. ## Proposed scope Add a resend request generation alongside the existing detail/retry generations, invalidate detail/resend generations on instance/scope changes, and guard all post-await UI effects. Keep the already-submitted backend mutation untouched; this only prevents its late client-side continuation from mutating a different scope. AI-assisted analysis and regression authoring; local red test executed against the current `master` baseline. -- 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]
