X-LightYear opened a new issue, #4545: URL: https://github.com/apache/rocketmq-dashboard/issues/4545
### 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: 987b748e8f4f421c5cd3c4c4e51a064cc7e59f18 deployed as: docker compose ### Runtime Environment OS: Windows 11 MySQL: not required for this reproduction browser: Chrome-compatible browser ### Connected RocketMQ Cluster RocketMQ version: 5.5.0 access mode: Proxy deployment: docker compose from deploy/rocketmq ### Build Toolchain _No response_ ### Describe the Bug `ConsumerPage.loadProgress` can apply an older asynchronous consumer progress response after a newer diagnostic request for the same consumer group has already completed. When progress requests overlap, such as during Health Diagnostics initialization and a manual "Re-diagnose", responses update the same `progressByGroup` entry in completion order. As a result, a stale response can overwrite the result of the newer diagnostic request. ### Steps to Reproduce 1. Open the Consumer page. 2. Open a consumer group detail dialog. 3. Switch to the Health Diagnostics tab. 4. While an earlier consumer progress request is still pending, click "Re-diagnose". 5. Let the newest request complete first, for example with `diffTotal=777`. 6. Let the older request complete afterward, for example with `diffTotal=13`. 7. Observe that the older result replaces the newer diagnostic result. This sequence is reproducible deterministically with deferred Promises in a frontend regression test. ### What Did You Expect to See? Only the newest progress request for the same instance and consumer group diagnostic context should be allowed to update the UI. After the newest request returns `diffTotal=777`, a stale response from an older request should be ignored and the UI should continue displaying `777`. ### What Did You See Instead? The newer request result is displayed first, but when the older request completes afterward, it overwrites the current `progressByGroup` entry. In the regression reproduction, the UI successfully displays `777`, then the stale response with `diffTotal=13` completes and replaces the newer result. ### Additional Context The issue is in: `web/src/pages/instance/consumer.tsx` Function: `loadProgress` The asynchronous response is written directly to `progressByGroup[cacheKey]` without checking whether the response still belongs to the latest request for that diagnostic context. A deterministic Vitest regression test was created locally using deferred Promises: 1. Start the older progress request. 2. Start the newest "Re-diagnose" request. 3. Resolve the newest request with `diffTotal=777`. 4. Confirm that `777` is rendered. 5. Resolve the older request with `diffTotal=13`. 6. The assertion that `777` remains visible fails because the stale response overwrites it. No arbitrary sleeps, real network timing, backend API changes, or RocketMQ protocol changes are required to reproduce the problem. The expected fix scope is frontend-only request ownership / generation handling in Consumer diagnostics. ### 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]
