zmuxuny opened a new issue, #6178: URL: https://github.com/apache/rocketmq-dashboard/issues/6178
### 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@5e4c39b0, verified 2026-10-10. ### Runtime Environment Deterministic UserManagement.test.tsx component test with mocked API and deferred mutation completion. Synthetic user/session fixtures only; no account or live session was changed. ### Connected RocketMQ Cluster Not applicable: Studio user-session administration, reproduced with mocked API responses and no live cluster. ### Build Toolchain _No response_ ### Describe the Bug When an administrator revokes user A's sessions, then closes A's drawer and opens user B's drawer before that revocation finishes, the completed A action can reload A's sessions into B's drawer. The drawer title still identifies B while its rows describe A. The continuation in web/src/pages/studio/UserManagement.tsx (revokeSessions, around line 331) checks sessionDrawerUser from its old render closure. It can therefore call loadSessionDetails(A) after B has become current. That obsolete reload increments the shared request sequence, so the read-side generation guard does not prevent the overwrite. ### Steps to Reproduce 1. Open user A's session drawer and start revoking A's sessions, with the revocation response delayed. 2. Close A's drawer and open user B's drawer; let B's session list load. 3. Complete the original A revocation request. 4. Observe A's reloaded sessions replacing B's rows beneath B's drawer title. ### What Did You Expect to See? Completing A's revocation may refresh appropriate overall user counts, but it must not replace B's session drawer or supersede B's pending read. A still-current A drawer should continue to refresh normally. ### What Did You See Instead? The deterministic regression fails against unchanged production source: B's session 99 is replaced by A's sessions 19/20 after the old action completes. Result: 1 failed, 12 skipped. These are synthetic fixture IDs, not real user/session data. No account or live session was changed. ### Additional Context ### Evidence A new deterministic component test, `does not replace another user session drawer when a previous revocation completes`, was run against unchanged production source: `npm test -- src/pages/studio/__tests__/UserManagement.test.tsx -t 'does not replace another'` ### Duplicate check Open #6113 addresses session-read failures rendered as an empty list; it does not guard revocation continuations. #5375 handles user modal mutations and failed lists. #5484 adds broader session lifecycle controls, but its patch does not fix the existing revoke-all-for-one-user continuation. Historical #1089 concerns consumer/LiteTopic details rather than Studio-user sessions. Current open PRs and historical searches for revokeSessions / revocation / stale session drawer found no matching fix. ### Acceptance criteria - A revocation completion only refreshes its drawer when that drawer still owns the same user/session generation. - Switching to B while A's mutation is pending keeps B's title and rows consistent. - Closing without reopening does not trigger an obsolete drawer read. - Revocation while staying on A continues to refresh A's session list. - Deterministic regression coverage includes deferred mutation completion. AI assistance was used for source inspection and deterministic regression authoring. ### 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]
