Wang1rrr opened a new issue, #4849: URL: https://github.com/apache/rocketmq-dashboard/issues/4849
### 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) MySQL: not required - reproduced with the web test harness against a mocked connections service browser (for UI issues): any; the affected page is web/src/pages/cluster/clients.tsx ``` ### Connected RocketMQ Cluster ``` RocketMQ version: 5.5.0, self-managed (the Apache provider is the only ClientProvider implementation) access mode: Direct to NameServer/Broker deployment: any cluster with a client whose LanguageCode has no ClientLanguage counterpart ``` ### Describe the Bug `ClientConnectionVO.language` is a nullable `ClientLanguage` (`cluster/client/ClientConnectionVO.java:40`), and `RocketMQClientProvider.mapLanguage` (`:439`) returns `null` for every `LanguageCode` that `ClientLanguage` has no name for - `RUBY`, `HTTP`, `OMS`, `OTHER`, `DELPHI`, `ERLANG`. The VO carries no `@JsonInclude(NON_NULL)` and there is no global inclusion override, so those clients are published as `"language": null`. The TypeScript contract does not say that. `web/src/api/connections.ts:10` declares `language: string`, while three sibling fields in the very same interface are already honest about the server being allowed to omit a value (`clientId?: string | null` `:6`, `address?: string | null` `:9`, `connectedAt?: string | null` `:12`). Because the type claims the field is always present, `strictNullChecks` cannot flag any of the unsafe uses, and there are four: - **the distribution chart** buckets connections with `` `${connection.language} ${connection.version}` `` (`clients.tsx:302`) and later splits that label back apart (`:806`), falling back to `{ color: 'default', label: language }` (`:808`). A client with no mapped language is therefore charted under the literal language **`null`** - the panel renders a grey tag reading `null 5.0.7: 1`; - **the Language column** renders `languageConfig[lang] ?? { color: 'default', label: lang }` (`:479`), which for `null` produces an **empty grey tag** in the table; - **the detail drawer** does the same lookup twice (`:976`), so the 语言 row shows an empty tag as well; - **the CSV export filter** compares `String(filterValue) === connection.language` (`:366`) against `null`, and the exported `Language` cell (`:113`) is blank. So the one place in the page that is supposed to summarise the fleet's SDK mix invents a language called `null`, and the two places that show a single connection's language show nothing at all. This is not a hypothetical input: `LanguageCode.OTHER` and `LanguageCode.HTTP` are what clients that do not identify their SDK report, and #4846 only removes one source of `null` (`NODE_JS`, which `ClientLanguage` does have a member for). The remaining six `LanguageCode` values have no `ClientLanguage` counterpart by design, so `language: null` is a permanent, expected part of the API response and the console has to render it. `version` is a different story and should stay non-nullable: `MQVersion.getVersionDesc(int)` returns `Version.values()[...].name()` on every path (it clamps out-of-range codes to the newest version), so the provider always sets a string. ### Steps to Reproduce 1. Console -> Cluster -> Clients, with a cluster selected. 2. Have one connected client whose broker-reported language has no `ClientLanguage` counterpart - an HTTP or OMS SDK client, or any client reporting `LanguageCode.OTHER`. 3. Look at the 语言 / 版本 distribution panel, the Language column for that row, and its 详情 drawer. ### What Did You Expect to See? A readable, localized placeholder for the unmapped language - the same treatment the page already gives other absent metadata through `displayMetadata` (`clients.tsx:152`, which renders `-` for a missing client id or address) - in the table cell, in the drawer, and as the bucket label in the distribution panel. ### What Did You See Instead? The distribution panel shows a tag literally labelled `null 5.0.7: 1`, and the table cell and the drawer both show an empty tag with no text at all. ### Additional Context Suggested fix, and the one in the pull request I am about to open: 1. declare the field the way the server actually sends it - `language?: string | null` - so `strictNullChecks` covers every consumer from now on; 2. bucket an unmapped language under a stable `unknown` key instead of letting `null` be interpolated into the chart label; 3. render a localized fallback for it. `common.unknown` (未知 / Unknown) does not exist yet, so the pull request adds it next to `common.unavailable`, reusing the wording `liteTopic.unknown` and `dashboardTraffic.trendUnknown` already use; 4. keep the export filter comparison well typed. `web/src/utils/clientConnectionDiagnostics.ts` needs no change: it already routes the field through `normalizeText(value?: string | null)` (`:109`) and reports `UNKNOWN_LANGUAGE` for it (`:315`), which is the honest reading of a client Studio cannot name. ### 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]
