Wang1rrr opened a new issue, #4843: URL: https://github.com/apache/rocketmq-dashboard/issues/4843
### 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 Aliyun converter, so the host does not matter MySQL: not required - reproduced at the converter layer against a mocked SDK response body browser (for UI issues): any; the affected console page is web/src/pages/instance/topic.tsx ``` ### Connected RocketMQ Cluster ``` RocketMQ version: Aliyun ApsaraMQ for RocketMQ 5.x (cloud instance, vendor ALIYUN) access mode: cloud OpenAPI through AliyunClientFactory (rocketmq20220801 SDK) deployment: any bound cloud instance with a credential; no self-managed cluster involved ``` ### Describe the Bug `TopicType` has five members and `LITE` is one of them (`common/domain/enums/TopicType.java:21`). Two of the three providers resolve a vendor type string with `TopicType.valueOf`, so every member round-trips: - Apache - `RocketMQMetadataProvider.parseTopicType` (`:204`): `TopicType.valueOf(type)`, falling back to `NORMAL` only for a genuinely unknown string; - Tencent - `TencentInstanceProvider.toTopicType` (`:1088`): `TopicType.valueOf(raw.trim().toUpperCase(Locale.ROOT))`, same fallback. The Aliyun converter hand-rolls the mapping instead and stops after four cases (`provider/alibaba/AliyunConverters.java:134`): ```java switch (messageType.toUpperCase(Locale.ROOT)) { case "NORMAL": return TopicType.NORMAL; case "FIFO": return TopicType.FIFO; case "DELAY": return TopicType.DELAY; case "TRANSACTION": return TopicType.TRANSACTION; default: // Unknown message types fall back to NORMAL so read paths (web // detail, AI rmq.topic.list) never see a null type, matching the // Apache provider's parseTopicType fallback. return TopicType.NORMAL; } ``` `LITE` is not a case, so it lands in `default` and is reported as `NORMAL`. The comment claims parity with the Apache fallback, but Apache's fallback never fires for `LITE` - Apache maps it. `LITE` is a documented Aliyun `messageType`: the 2022-08-01 `CreateTopic` API lists `NORMAL / FIFO / DELAY / TRANSACTION / LITE (轻量主题消息)`, Aliyun ships LiteTopic as a product feature, and `ListTopicsResponseBody.List.messageType` carries the same vocabulary. So this is a value the SDK really returns, not a hypothetical string. Everything downstream of `toTopicVO` (`:118`) then describes a lite topic as an ordinary one: - the type tag renders 普通消息 instead of LiteTopic, even though `TOPIC_TYPE_MAP.LITE` (`web/src/constants/theme.ts:60`) and the `theme.topicLite` dictionary entry (`web/src/i18n/translations.ts:2268`) already exist and are exercised by `theme.test.ts:71`; - the LiteTopic entry in `TYPE_OPTIONS` (`web/src/pages/instance/topic.tsx:139`) never matches, so filtering an Aliyun instance by LiteTopic returns an empty list even when lite topics exist; - `canSendTestMessage = !isCloudInstance || topic.type === 'NORMAL'` (`topic.tsx:353`) becomes true for a mis-typed lite topic, so the console offers to send a plain test message to a topic whose contract is not a plain topic; - the AI tool path reads the same VO, so `rmq.topic.list` tells the model the topic is NORMAL; - CSV export writes `toText(topic.getType())` into the `Type` column (`instance/topic/MetadataService.java:791`), so exporting an Aliyun instance and re-importing the file turns every lite topic into a NORMAL one. The importer accepts `LITE` (`web/src/utils/resourceCsvImport.ts:70`) but never receives it. A lite topic is reachable on an Aliyun instance from Studio itself, which is what makes the round trip observable: the create dialog hides the LiteTopic card for cloud instances (`topic.tsx:1799`), but the 导入 button beside it is only disabled when no instance is selected (`topic.tsx:1613`) and the CSV validator accepts `Type=LITE`, so `POST /api/topics/import` -> `MetadataService.importTopics` (`:727`) -> `createTopic` sends `messageType=LITE` to Aliyun. Aliyun creates the lite topic, and Studio then displays it as NORMAL. ### Steps to Reproduce 1. Bind an ALIYUN cloud instance with a credential. 2. Create a lite topic on it - either through the console's 导入 CSV flow with a row carrying `Type=LITE`, or with `POST /api/topics/create`, or in the Aliyun console / OpenAPI directly. 3. Console -> Topic, with that instance selected. Filter the list by LiteTopic, then export the list to CSV. ### What Did You Expect to See? The topic listed with the LiteTopic tag, matched by the LiteTopic filter, exported as `Type=LITE`, and reported as `LITE` by `rmq.topic.list` - the same way the Apache and Tencent providers report `TopicType.LITE`. ### What Did You See Instead? 普通消息 / `NORMAL` in all of them, and the 发送测试消息 action offered for the topic because the guard only checks `type === 'NORMAL'`. ### Additional Context Suggested fix, and the one in the pull request I am about to open: add the missing `case "LITE": return TopicType.LITE;` to `AliyunConverters.toTopicType` so the converter covers the same vocabulary as `TopicType`, and keep `default` for a value a future vendor release may introduce. Tests pin each documented messageType, the lower-case spelling, the unknown-value fallback and the `toTopicVO` list path. Worth a separate discussion, deliberately not part of that fix: `topic.tsx:1799` hides the LiteTopic card for **every** cloud instance, while `isCloudInstance` covers both ALIYUN and TENCENT and only Tencent rejects `LITE` server-side (`TencentInstanceProvider.java:1132`). If Aliyun LiteTopic should be creatable from the console, that filter has to become vendor-specific. ### 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]
