Wang1rrr opened a new issue, #4845: URL: https://github.com/apache/rocketmq-dashboard/issues/4845
### 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 `rocketmq-studio` branch (the Studio trunk the pull request template points at), commit `4c697f07acde460e2344375cb1f82669f5b270fd`. ### Studio Version ``` branch: rocketmq-studio git commit id: 4c697f07acde460e2344375cb1f82669f5b270fd deployed as: built from source ``` ### Runtime Environment ``` OS: Windows 11 (development box); the defect is in the Apache provider's enum mapping, so the host does not matter MySQL: not required - reproduced at the provider layer against a mocked MQAdminExt producer table browser (for UI issues): any; the affected console page is web/src/pages/cluster/clients.tsx ``` ### Connected RocketMQ Cluster ``` RocketMQ version: 5.5.0 (rocketmq-remoting 5.5.0 on the Studio classpath), self-managed access mode: Direct to NameServer/Broker - the same path serves Proxy Local and Proxy Cluster deployment: any cluster with at least one Node.js SDK client connected ``` ### Describe the Bug `ClientLanguage` has eight members (`common/domain/enums/ClientLanguage.java:21`): ```java Java, Go, Python, Rust, Cpp, CSharp, NodeJS, PHP ``` `RocketMQClientProvider.mapLanguage` (`provider/apache/RocketMQClientProvider.java:439`) is the only place that turns a broker-reported `LanguageCode` into one of them, and its switch has seven cases - `JAVA`, `GO`, `PYTHON`, `RUST`, `CPP`, `DOTNET`, `PHP` - with `default: return null`. `LanguageCode.NODE_JS` exists in rocketmq-remoting 5.5.0 (`javap org.apache.rocketmq.remoting.protocol.LanguageCode` lists it after `RUST`), so a Node.js client falls through to `null` and `ClientConnectionVO.language` (`cluster/client/ClientConnectionVO.java:40`) is serialized as `"language": null` - the VO carries no `@JsonInclude(NON_NULL)` and there is no global inclusion override. The console is already built to display that value, which is what makes the gap visible: - `web/src/pages/cluster/clients.tsx:101` has `NodeJS: { color: 'lime', label: 'Node.js' }` in `languageConfig`, so the tag, the drawer (`:975`) and the distribution panel all have a rendering ready that never gets used; - the Language column filter is generated from that map (`:473`) and matched with `onFilter: (value, record) => record.language === value` (`:478`), so the Node.js filter option is offered and can never match anything; - the tag renderer falls back to `languageConfig[lang] ?? { color: 'default', label: lang }` (`:480`), which for `null` draws an empty grey tag; - the Language/Version distribution buckets connections with `` `${connection.language} ${connection.version}` `` (`:302`) and later splits that label back apart (`:806`), so a Node.js client is charted under the literal language `null`; - the CSV export writes the same field into its `Language` column (`:113`), i.e. an empty cell. The client diagnostics then treat the missing value as a defect in the user's fleet. `web/src/utils/clientConnectionDiagnostics.ts:107` lists `KNOWN_LANGUAGES` including `'NodeJS'`, `normalizeText` (`:109`) turns `null` into `'unknown'`, and `:315` raises an `UNKNOWN_LANGUAGE` issue - 客户端语言未知 / 该客户端连接的语言不在 Studio 已知语言列表中 - for every single Node.js connection. So a perfectly healthy Node.js SDK client is reported both as an unknown language in the diagnostics panel and as `null` in the distribution chart, and the operator is told to 确认客户端 SDK 语言和采集字段 when the field Studio failed to map is its own. This is the same shape as the Aliyun `TopicType.LITE` gap: a hand-rolled switch over a vendor vocabulary that has drifted from the Studio enum it feeds, while the rest of the stack already supports the missing member. ### Steps to Reproduce 1. Start a self-managed RocketMQ cluster and connect any Node.js SDK client (a `rocketmq-clients` Node.js producer or consumer is enough). 2. Console -> Cluster -> Clients, with that cluster selected. 3. Look at the Language column, the Language filter, the 语言/版本 distribution panel and the client diagnostics for that connection. ### What Did You Expect to See? The connection tagged `Node.js` (lime), matched by the Node.js filter option, bucketed as `NodeJS <version>` in the distribution panel, exported as `NodeJS` in the CSV, and no `UNKNOWN_LANGUAGE` diagnostic - i.e. the same treatment the other seven `ClientLanguage` members already get. ### What Did You See Instead? An empty tag in the Language column, a Node.js filter option that matches nothing, a `null` bucket in the distribution chart, an empty CSV cell, and an `UNKNOWN_LANGUAGE` (客户端语言未知) diagnostic on every Node.js connection. ### Additional Context Suggested fix, and the one in the pull request I am about to open: add `case NODE_JS: return ClientLanguage.NodeJS;` to `mapLanguage`, and pin the mapping with a test that asserts every `ClientLanguage` member is producible from the scan, so the next enum member cannot be silently dropped. `LanguageCode` values with no `ClientLanguage` counterpart (`RUBY`, `HTTP`, `OMS`, `OTHER`, `DELPHI`, `ERLANG`) should keep returning `null` - for those the `UNKNOWN_LANGUAGE` diagnostic is honest. Follow-up worth its own change, deliberately not bundled here: `clients.tsx:302` interpolates a nullable field into the distribution label, so *any* unmapped language still shows up as the literal `null` in that chart. Guarding that label belongs in the web layer. ### 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]
