zmuxuny opened a new issue, #6192: URL: https://github.com/apache/rocketmq-dashboard/issues/6192
### 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@5e4c39b053c35a5598cc79ff331b8a54e649d7b1 ### Runtime Environment Deterministic frontend component regressions using mocked inventory and delete services; no real accounts changed. ### Connected RocketMQ Cluster Not required for the component reproduction. ### Build Toolchain _No response_ ### Describe the Bug ### Studio version `rocketmq-studio@5e4c39b0`, verified 2026-10-10. ### Describe the bug Cloud Credentials and Data Sources capture their current inventory-loading callback when a deletion starts. If the operator changes the search or page while the deletion is pending, the new query can load successfully, then the completed deletion calls its captured old loader and replaces the current inventory with old-query results. The request-generation guards do not help: the obsolete refresh starts later and receives a newer generation. Data Sources displays the old-query rows under the new search and leaves them actionable. Cloud Credentials has a separate loaded-query guard: the old response records its old query key, so the current query mismatches and the table can remain loading with actions disabled until another query change. This report does not claim Cloud Credentials leaves the mismatched rows actionable. The deletion completion's last-row page adjustment also uses the old page and old row count. ### Steps to reproduce 1. On Cloud Credentials or Data Sources, begin deleting an inventory entry and delay the delete response. 2. Change the search to another value and wait for the filtered list to load. 3. Complete the original deletion. 4. Observe another list request using the old search. Data Sources replaces the filtered results; Cloud Credentials becomes stuck behind its query-mismatch loading/action guard. ### Evidence Two deterministic component regressions reproduce the defect against unchanged production source. Each defers deletion, searches for `prod` or `stage`, waits for the new results, then resolves the old deletion. The third list request uses the old empty/undefined search instead of the current filter. `npm test -- src/pages/settings/__tests__/CloudCredentialTab.test.tsx src/pages/settings/__tests__/DataSourceTab.test.tsx -t 'deletion completes after search changes' --maxWorkers=1` Initial result: 2 failed, 27 skipped. Expanded current-query tests: 4 failed, 2 passed, 27 skipped. In each page, a last-row deletion started on page 3 incorrectly moves a newly selected page 1 back to page 2; the two same-query page-3-to-page-2 controls pass. Fixture names are synthetic; no real credentials, data sources or accounts were changed. Affected paths: delete completion and page adjustment in `web/src/pages/settings/CloudCredentialTab.tsx` and `web/src/pages/settings/DataSourceTab.tsx`. ### Expected behavior A completed deletion refreshes the inventory currently being viewed without reintroducing an old filter or jumping to an obsolete page. Search debounce and pagination transitions must continue to use a coherent current-query scope. ### Duplicate check - #5253 / #5054 prevent stale credential actions after a failed reload, not obsolete post-delete refreshes. - #5495 clears failed inventory loads. - #5497 adds duplicate-mutation guards. - #5216 protects data-source modal sessions from old save completions. Open and historical searches for both loader names, delete/filter changes, and the `remainingOnPage` path found no matching fix. ### Acceptance criteria - Both settings inventories preserve the current filter after an older deletion completes. - Pending search debounce and page changes are covered. - A last-row deletion cannot move a newer query to the old query's prior page. - Normal same-query deletion still refreshes the inventory and handles an emptied page appropriately. - Group both instances of the same stale-query continuation bug into one regression-backed change. AI assistance was used for source inspection and deterministic regression authoring. ### Steps to Reproduce Start a deletion and defer its response, switch search or page and wait for the current inventory, then complete the old deletion. See the detailed reproduction and evidence above. ### What Did You Expect to See? Refresh only the currently viewed query; preserve coherent debounce and pagination scope. Same-query last-row deletion should still adjust its page normally. ### What Did You See Instead? The completion issues an obsolete-query request or jumps to an obsolete page. Data Sources displays old actionable rows; Cloud Credentials instead becomes stuck behind its loaded-query mismatch guard. ### Additional Context _No response_ ### 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]
