X-LightYear opened a new issue, #4547: URL: https://github.com/apache/rocketmq-dashboard/issues/4547
### 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 branch: master git commit id: d50ffecc9d7e8f8f46da64198831bd7952e6974e deployed as: docker compose ### Runtime Environment OS: Windows 11 MySQL: not required for this reproduction browser: Google Chrome 127.0.6533.120 (64-bit) on Windows 11 ### Connected RocketMQ Cluster RocketMQ version: 5.5.0 access mode: not relevant to this frontend race reproduction deployment: docker compose from deploy/rocketmq ### Build Toolchain _No response_ ### Describe the Bug The Topic sync modal can apply a stale asynchronous route-check result after a newer sync check has already completed. If the modal is closed and reopened while the previous route-check request is still pending, the older request can later overwrite the result of the new modal session. This can cause the UI to report missing Broker routes even after the latest sync check has already confirmed that all Topics have valid routes. ### Steps to Reproduce 1. Open the Topic page. 2. Click "Sync Data" and keep the first route-check request pending. 3. Close the sync modal. 4. Open "Sync Data" again, starting a second route-check request. 5. Resolve the second request with a valid Broker route. 6. Confirm that the UI reports that all Topics have routes. 7. Resolve the first request afterward with an empty route list. 8. Observe that the stale first request changes the current modal result to report missing routes. This sequence is reproducible deterministically with deferred Promises in a frontend regression test. ### What Did You Expect to See? Only the latest route-check request for the current sync-modal session should be allowed to update the UI. After the second request confirms that all Topics have valid routes, completion of the older request should be ignored and the healthy result should remain visible. ### What Did You See Instead? The newer request completes successfully and the UI reports that all Topics have valid routes. When the older request completes afterward, it updates the current sync state and the UI incorrectly changes to report missing routes. ### Additional Context The issue is in: `web/src/pages/instance/topic.tsx` Function: `openSyncModal` The asynchronous route-check flow updates shared state such as: - `routesByTopic` - `syncMissing` - `syncChecking` without tracking which modal session or request generation owns the result. As a result, overlapping route-check requests update the same state in completion order rather than request ownership order. A deterministic Vitest regression test was added locally: `web/src/pages/instance/__tests__/TopicPage.test.tsx` Test: `keeps a reopened sync modal owned by its newest route check` The test uses deferred Promises to: 1. keep the first route check pending; 2. close and reopen the sync modal; 3. resolve the newer check with a valid route; 4. confirm that the healthy result is rendered; 5. resolve the stale request with no route; 6. verify that the stale result must not replace the current result. The current production implementation fails the final assertion. Existing TopicPage tests still pass: - 26 existing tests passed - only the new regression test failed Frontend lint for the modified test file passes, and `npm run build` also passes. The expected fix scope is frontend-only Topic synchronization modal state management. No backend API or RocketMQ protocol change is required. ### 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]
