Frun1na opened a new issue, #4652: URL: https://github.com/apache/rocketmq-dashboard/issues/4652
### Environment * rocketmq-dashboard branch: rocketmq-studio (commit 5b761df8) ### What happened In `useQueueBrowser` (web/src/components/QueueBrowser.tsx), the `finally` block of an in-flight queue pull clears its key from `pullingRef` unconditionally — even when the request has already gone stale (an instance or topic switch bumped the request sequence and the reset effect cleared `pullingRef`). When the user switches to another topic that has a queue with the same broker/queue id (`brokerName-queueId` keys are only unique within one topic), a new pull re-claims the same key in `pullingRef`. The stale pull's `finally` then deletes that key, so the duplicate-pull guard no longer blocks further clicks on the same queue: duplicate concurrent pulls go out and the pulled-entries list flickers between their results. ### What should happen A stale request should not touch the pulling-slot state at all — the `finally` block should apply the same request-sequence staleness guard the rest of the handler already uses. ### Additional context PR with fix and tests: #4651 -- 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]
