iloveeyjafjalla opened a new issue, #6320: URL: https://github.com/apache/rocketmq-dashboard/issues/6320
### 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: 5e4c39b053c35a5598cc79ff331b8a54e649d7b1 deployed as: built from source - backend run with `java -cp target/classes:<deps> org.apache.rocketmq.studio.StudioApplication`, frontend `npm run dev` in real-data mode ### Runtime Environment OS: Windows 11 (backend and frontend run on the host) MySQL: 8.0.46 in Docker Desktop, schema loaded from server/src/main/resources/db/schema.sql browser (for UI issues): in-app browser (Chromium 141) at 1280x720 ### Connected RocketMQ Cluster RocketMQ version: 5.3.2 (official apache/rocketmq:5.3.2 image) access mode: Direct to NameServer (127.0.0.1:9876) deployment: single NameServer + single broker ("broker-a") started from the official image ### Build Toolchain JDK: Temurin 21.0.12 Maven: 3.9.9 Node.js: 20.19.5 ### Describe the Bug The summary tiles in the connection statistics block are computed from a `Map` keyed by `${type}:${clientId}`, so they count **de-duplicated clients**, while the first tile is labelled `t('clients.title')` - the same string as the page title - and the page subtitle and the table footer both count **connections**. On a real cluster the two numbers diverge as soon as one client serves more than one group, which is the normal case: a Java client registers its own group *plus* the shared `CLIENT_INNER_PRODUCER`. The value shown is not the connection count and not the unique-client count either - it is the number of distinct (type, clientId) pairs, so a client that is both a producer and a consumer is counted twice. The de-duplicated view already exists in the diagnostics panel below ("unique clients" / "unique addresses"), which reported 4 / 4 while the tile reported 5. Mock mode hides this: the mock fixture has 15 connections over 15 distinct clients, so both numbers coincide and the existing tests never see the divergence. ### Steps to Reproduce 1. Start Studio against a real broker in Direct mode (backend and frontend from source). 2. Let the console itself open a connection: send one message through 消息查询 → 发送. The pooled producer registers `studio-pool-producer`, `CLIENT_INNER_PRODUCER` and an inner trace producer on the broker. 3. Register the NameServer in 集群管理 → NameServer 注册表 (the clients endpoint requires a registered endpoint), then open 集群管理 → 客户端连接. 4. Compare the page subtitle and the table footer with the summary tiles. ### What Did You Expect to See? The summary describes the connections the table below lists: 客户端连接 7, Producer 6, Consumer 1, protocol distribution Remoting: 7, and the language/version distribution counted per connection as well. The de-duplicated counts stay where they are already reported: the diagnostics panel. ### What Did You See Instead? Page subtitle: `客户端连接 — 7 connections`; table footer: `共 7`; the table renders 7 rows. Summary tiles: 客户端连接 **5** (expected 7), Producer **4** (expected 6), Consumer 1, `Remoting: 5` (expected 7), `Java V5_5_0: 5` (expected 7). So the same screen presents two different "connection" counts, and the tile value matches no label that can be put on it: it is neither 7 (connections) nor 4 (unique clients). ### Additional Context - Code: `web/src/pages/cluster/clients.tsx`; the `connectionStats` memo builds a `Map` keyed by `${connection.type}:${connection.clientId ?? connection.address ?? connection.groupOrTopic}` and derives `total` / `producers` / `consumers` / `protocols` / `languageVersions` from it. - Broker-side ground truth for the same clients (`mqadmin producerConnection` for one topic): 4 connections in `CLIENT_INNER_PRODUCER` + 1 in `studio-pool-producer` + 1 inner-trace producer = 6 producer connections, which matches the 6 rows the table lists. - The commit that introduced the tiles (45a510af, "feat: add client connection distribution statistics") ships no test that pins the de-duplication, so nothing turned red. - Verified locally on the same broker: with the fix the tiles report 7 / 6 / 1 / Remoting: 7 while the diagnostics panel keeps 唯一 Client 4 / 唯一地址 4; `ClientsPage.test.tsx` is 25/25 green and the new case fails on the previous code. - AI assistance: the reproduction, the fix and the regression test were prepared with AI assistance (OpenAI Codex / ZCode). Every claim above was verified against the running stack before it was written down. A pull request referencing this issue is submitted. ### 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]
