zmuxuny opened a new issue, #7177: URL: https://github.com/apache/rocketmq-dashboard/issues/7177
### 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 at 127c47b06a268cc74224d5f34c56ec7c36ac0d55 ### Runtime Environment Linux; Node.js 24.19.0; Vitest 4.1.10/jsdom with the real Ant Design components. Reproduced in isolated frontend tests with deferred/rejected API mocks. ### Connected RocketMQ Cluster No live cluster required. The reproduction controls nameserver registry and client-connection API responses; no real cluster or database was contacted. ### Build Toolchain _No response_ ### Describe the Bug The Clients diagnostic panel analyzes the initial/cleared empty connections array before a current inventory request has succeeded. While the registry or connection request is pending, after a read fails, or when no nameserver is registered, it reports critical risk, 76/100, and no connected clients. An unavailable inventory is not evidence that no clients exist. The load-error warning can appear together with this false diagnosis. ### Steps to Reproduce 1. Open Clients and delay the registry or client-connection response. The diagnostic panel already reports no connections before a response. 2. Reject the connection request, or reject the registry request / return no registered endpoints. The same critical diagnosis remains. 3. After a successful response, change nameserver, cluster or client type and hold the replacement request. Diagnostics should not describe the cleared array as the new inventory. 4. For a retry edge case: load an empty ALL result successfully, switch to a type whose read fails, return to ALL and fail again, then retry with registry loading finishing before the connection read. The earlier empty diagnosis must not reappear while the new read is pending. ### What Did You Expect to See? Show diagnostics only after the connection inventory for the current endpoint/cluster/type has been successfully read. Keep the existing critical 76/100 result when a successful response really contains no clients. Failed/pending reads should rely on the existing loading/error UI instead of inventing an empty-inventory diagnosis. ### What Did You See Instead? The panel displays critical, 76/100, 客户端连接存在高风险 and 未发现客户端连接 even when the current inventory is unknown. Eight focused real-AntD regression cases fail against the unmodified base; the successful-empty control passes. ### Additional Context The proposed focused fix tracks which endpoint/cluster/type query actually completed, invalidates that marker at the start of a read, and gates the diagnostic panel. It does not change the diagnostic algorithm. Nine regression cases plus the related Clients/diagnostics/filter suite pass (55 tests, 5 files); forced TypeScript build, changed-file ESLint and Prettier also pass. No full frontend suite, bundle build or live-cluster test was run. Deduplication: #7058 changes diagnostic grouping/metadata/partial-scan semantics; this report concerns whether any current inventory was successfully read. The request-ordering fixes are already present in this base. ### 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]
