iloveeyjafjalla opened a new issue, #6204: URL: https://github.com/apache/rocketmq-dashboard/issues/6204
# [Bug] Normal connections to multiple brokers are reported as critical Client ID collisions ### Studio Version `rocketmq-studio@5e4c39b053c35a5598cc79ff331b8a54e649d7b1`. ### Runtime Environment / Build Toolchain Reproduced with the existing frontend unit and real `ClientsPage` component tests on Windows 11, Node 24.15.0 and npm 11.12.1. The component test supplies controlled service results matching the production provider's record shape. No live broker deployment or customer incident is claimed. ### Connected RocketMQ Cluster The affected path is the Apache Remoting connection inventory for a client connected to multiple brokers. The production data flow is established from RocketMQ 5.5.0 and Studio source; the automated reproduction uses service fixtures. ### Describe the Bug `analyzeClientConnections` treats any two distinct full socket addresses for one client ID as a critical `CLIENT_ID_COLLISION`. A normal client process uses the same client ID while connecting to different brokers, and its TCP source port can differ on each connection. This is not evidence of a client ID clash. The production chain is: - [ClientConfig.buildMQClientId](https://github.com/apache/rocketmq/blob/rocketmq-all-5.5.0/client/src/main/java/org/apache/rocketmq/client/ClientConfig.java#L109) builds an ID from client IP and instance name, independent of socket source ports. - [MQClientInstance.sendHeartbeatToAllBroker](https://github.com/apache/rocketmq/blob/rocketmq-all-5.5.0/client/src/main/java/org/apache/rocketmq/client/impl/factory/MQClientInstance.java#L621) sends the same heartbeat identity to the discovered brokers. - [AdminBrokerProcessor](https://github.com/apache/rocketmq/blob/rocketmq-all-5.5.0/broker/src/main/java/org/apache/rocketmq/broker/processor/AdminBrokerProcessor.java#L1663) reports each connection's remote socket address. Studio's `RocketMQClientProvider` preserves those addresses in its union of broker connection records. ### Steps to Reproduce 1. Query the client connections inventory for a normal client connected to two brokers. 2. The same client ID can appear with addresses such as `192.0.2.10:51001` and `192.0.2.10:51002`. 3. Open Cluster → Clients and inspect the connection diagnostics. The equivalent deterministic component regression feeds those two Producer/Remoting records through the existing `listConnections` service boundary, waits for both addresses to render, and checks the diagnostics panel. On unchanged production code the panel reports a critical collision. The utility returns score 76 with `CLIENT_ID_COLLISION` as its only issue. ### Expected / Actual Expected: a different source port on the same host should not by itself report a critical client ID collision. Records on genuinely different hosts should retain the existing possible-collision warning. Actual: ordinary multiple-broker connections are reported as a high-risk client ID collision. ### Validation and Scope The expanded utility/page suite against old production code reports 32/36 tests passing and four expected failures: IPv4, IPv4 socket notation, bracketed IPv6, and the real page diagnostics regression. The three related test files pass 37/37 after the proposed minimal fix. The fix compares host portions only for collision classification. Full addresses, record identities, exact-duplicate checks, evidence, and inventory counts stay intact. Unrecognized address formats retain the existing comparison; ambiguous bare IPv6 and hostname aliases are not newly interpreted. Existing aggregated fields cannot distinguish two deliberately conflicting processes on the same host from normal multiple-broker connections, so this is a correction to a heuristic, not a comprehensive identity guarantee. ### Before Creating the Bug Report - [x] Searched both open and closed issues/PRs and inspected relevant current PR head diffs. - [x] This is a Studio frontend diagnostics defect in this repository. - [x] The reproduction is based on the exact `rocketmq-studio` commit above. PR #5570 changes diagnostic translations, PR #6088 removes unavailable connection-time fields, and historical #4611/#4617 concern resource rollups; their actual diffs do not fix this socket-port collision test. No dedicated tracking issue or implementing fix was found in the audit snapshot. AI assistance: OpenAI Codex was used to investigate, implement and run automated checks, including a separate automated code review. No human or maintainer approval is claimed. ### Implementation PR The implementation PR will be linked after publication. -- 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]
