Frun1na opened a new issue, #6522: URL: https://github.com/apache/rocketmq-dashboard/issues/6522
### 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 `rocketmq-studio` branch, or I have stated the exact version I am running below. ### Studio Version branch: `rocketmq-studio` git commit id: `779b8c0e` deployed as: reproduced by a unit test against that commit (the affected code is the web client) ### Runtime Environment OS: Ubuntu on WSL2 MySQL: not applicable — the defect is in the web client's state handling browser: not applicable — reproduced in a jsdom unit test (vitest + Testing Library) ### Connected RocketMQ Cluster RocketMQ version: not applicable — reproduced with a stubbed users API in a unit test access mode: not applicable deployment: not applicable ### Describe the Bug After a session revocation or a status switch on the users page, the list refresh re-issues the query that was captured when the operator confirmed the action, not the one on screen (`web/src/pages/studio/UserManagement.tsx`): ```tsx const setEnabled = (record: StudioUser, enabled: boolean) => runUserMutation( record.id, async () => { await setStudioUserEnabled(record.id, enabled); ... await loadUsers(); // the `loadUsers` of the render that started the mutation }, t('userMgmt.updateStatusFailed'), ); ``` `loadUsers` is a `useCallback` over the search, the role and status filters, the page and the page size, so the continuation re-queries the state as it was when the operator confirmed. Both the status switch and the two revoke popovers leave the page interactive, so narrowing the search (or moving to another page) while the request is on the wire makes the follow-up refresh write the older query's rows and total over the newer result: the table then shows rows the search box no longer selects. `#6198` fixed the same shape for the cloud-credential and data-source tabs. ### Steps to Reproduce Reproduced by a component test rather than against a server: 1. Render the users page; a row with active sessions is listed. 2. Confirm "注销" (revoke) on that row and hold the `revokeStudioUserSessions` response pending. 3. Type a search term while the request is on the wire, so the list reloads for the new term. 4. Resolve the revoke: the follow-up `listStudioUsers` call carries `search: undefined` (the value captured at confirm time) and the table returns to the rows the new search excluded. ### What Did You Expect to See? The refresh after the mutation should run against the query the operator is looking at, the way `#6198` made the settings tabs do it. ### What Did You See Instead? `listStudioUsers` is called once more with the old `search` (and the old page) and its result replaces the table, so the rendered rows and the search box disagree. ### Additional Context - A fix with a regression test follows in a pull request. - The case is pinned by a unit test that fails without the fix: `AssertionError: expected { search: undefined, …(4) } to deeply equal ObjectContaining {"search": "current"}`. ### 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]
