unbridled-41 opened a new issue, #5125: URL: https://github.com/apache/rocketmq-dashboard/issues/5125
### 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: rocketmq-studio git commit id: 4ee173ad71ae777f01111394a88358958b9abad6 deployed as: built from source; the evidence below is the repository's own test suite run against that revision, not a deployed instance ``` ### Runtime Environment ``` OS: Ubuntu on Linux 6.6.87.2-microsoft-standard-WSL2 Node.js: v24.20.0 browser (for the test runner): jsdom (vitest), not a real browser session ``` ### Connected RocketMQ Cluster None. The defect is in the console's consumer-group diagnostics modal (`web/src/pages/instance/consumer.tsx`); the evidence stubs `consumerService.getConsumerSubscriptions`. ### Describe the Bug `loadSubscriptions` (`web/src/pages/instance/consumer.tsx:390-422` at the commit above) raises the per-group loading flag for a user-visible check but clears it only when the finishing request is both current **and** non-silent (`:415-419`): ```ts if (subscriptionRequestIdRef.current[cacheKey] === requestId && !silent) { setSubscriptionLoadingByGroup((prev) => ({ ...prev, [cacheKey]: false })); } ``` The detail modal refreshes the same data silently every two seconds (`tick` at `:454-476`, the interval at `:474` calling `await loadSubscriptions(groupName, true, true)` at `:467`). When a tick lands while a user-visible check (the modal opening, the 健康诊断 tab, or the 重新检查 button) is still in flight, the silent call takes over the current-request slot. Then neither request can clear the flag, in either resolution order: the older one is no longer current, and the silent one is excluded by `!silent`. `subscriptionLoadingByGroup[cacheKey]` stays `true` for that group. The `!silent` half of the guard was introduced by `c3cbae02` ("fix(web): ignore stale consumer subscription responses", #4968), which turned the previous `if (!silent)` into the two-condition form above. ### Steps to Reproduce Run the regression test from the pull request below against the base revision of the component: ```bash git show origin/rocketmq-studio:web/src/pages/instance/consumer.tsx > web/src/pages/instance/consumer.tsx cd web && npx vitest run src/pages/instance/__tests__/ConsumerPage.test.tsx \ -t 'stops the subscription check spinner when a silent refresh supersedes it' cd .. && git checkout -- web/src/pages/instance/consumer.tsx ``` The test opens the modal with a deferred subscription response (the user-visible check keeps `subscriptionLoadingByGroup[groupId] = true`), lets the modal's 2s auto-refresh issue its silent request, resolves both, and then asserts the 重新检查 button is no longer in the loading state. Observed output at that revision: ```text FAIL src/pages/instance/__tests__/ConsumerPage.test.tsx > Consumer page > stops the subscription check spinner when a silent refresh supersedes it Error: expect(element).not.toHaveClass("ant-btn-loading") Expected the element not to have class: ant-btn-loading Received: ant-btn css-dev-only-do-not-override-mncuj7 ant-btn-default ant-btn-color-default ant-btn-variant-outlined ant-btn-sm ant-btn-loading ``` ### What Did You Expect to See? The newest request for a group should clear the loading flag whichever way it was started, while a response from a superseded request must keep being ignored (the behaviour #4968 established). Acceptance criteria: the new test passes, and the existing staleness tests still pass — `ConsumerPage.test.tsx#ignores stale subscription responses after a newer diagnostic request completes` and `ConsumerPageDiagnosticsRace.test.tsx`. ### What Did You See Instead? The flag stayed `true` after both requests had settled, so the 订阅一致性检查 panel kept its spinner (`:1817`) and the alert could keep showing "正在检查订阅一致性" while the result table was empty (`:1841-1843`), until the operator triggered a non-silent check again. The check result itself was not affected: the response of the newest request is still the one applied. ### Additional Context - #4961 (closed) is the defect that #4968 fixed (a stale subscription response overwriting a newer diagnostic result); this report is about the loading state that fix left behind. - Open PRs #4983 and #4984 fix the same *class* of stranded loading flag on other pages (metrics profile, ACL and system alerts); this report is the consumer diagnostics surface, and neither touches `consumer.tsx` or `subscriptionLoadingByGroup`. Pull request with the fix and the regression test: #5121 -- 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]
