zmuxuny opened a new issue, #7097: URL: https://github.com/apache/rocketmq-dashboard/issues/7097
### 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 ### Runtime Environment Frontend regression tests in Linux, Node 24.19.0, Vitest/jsdom; controlled Axios adapter and fetch responses reproduce the request ordering without a live server. ### Connected RocketMQ Cluster Not cluster-specific; reproduces in the frontend authentication handling before any broker interaction. ### Build Toolchain _No response_ ### Describe the Bug A protected request started under an earlier login can return HTTP 401 after the user has logged out and logged in again in the same SPA. Both the Axios response interceptor and AI send/attach fetch paths unconditionally clear the current persisted session and navigate to /login. The old response therefore destroys a newer valid login, including a new login as the same user. ### Steps to Reproduce 1. Log in and start a protected Axios request, AI send stream, or AI attach stream; delay its response. 2. Log out and complete a new login while that request is pending. 3. Resolve the old request with HTTP 401. 4. Inspect the persisted new session and the hard-navigation call. The regression suite also repeats this with the same username, so username comparison cannot reliably establish request ownership. ### What Did You Expect to See? Reject the old request with its original 401, but preserve the newer login and do not redirect it. A 401 belonging to the current login must still clear its session and redirect to /login. ### What Did You See Instead? Four controlled stale-response cases clear the new login and invoke /login once. Three current-session controls pass, confirming that ordinary expiry handling should remain intact. ### Additional Context Fail-before: 4 failed / 3 passed / 48 skipped with src/api/client.test.ts and src/api/ai.test.ts, before production changes. Searched existing 401/session/relogin reports and checked related #5336, #5246, #5361 and #5484; those address expiry routing, cross-tab state or server session features rather than old in-flight response ownership. This report is limited to a single SPA lifecycle. ### 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]
