Wang1rrr opened a new pull request, #4844:
URL: https://github.com/apache/rocketmq-dashboard/pull/4844
<!-- Make sure the base branch is `master`: that is the RocketMQ Studio
trunk. -->
### Which Issue(s) This PR Fixes
- Fixes #4843
### Brief Description
`AliyunConverters.toTopicType`
(`provider/alibaba/AliyunConverters.java:134`) is the only place where an
Aliyun `messageType` string becomes a `TopicVO.type`, and it hand-rolls a
switch over four values with `default: NORMAL`. `LITE` falls into that default,
so every lite topic on an Aliyun instance is reported to Studio as an ordinary
one.
The other two providers do not have this hole because they resolve through
the enum:
| provider | mapping | `LITE` |
| --- | --- | --- |
| Apache | `RocketMQMetadataProvider.parseTopicType` (`:204`) ->
`TopicType.valueOf(type)` | preserved |
| Tencent | `TencentInstanceProvider.toTopicType` (`:1088`) ->
`TopicType.valueOf(raw.trim().toUpperCase(Locale.ROOT))` | preserved |
| **Aliyun** | **`AliyunConverters.toTopicType` (`:134`) -> four-case
switch** | **downgraded to `NORMAL`** |
`LITE` is not a hypothetical value. Aliyun's 2022-08-01 `CreateTopic`
documents `messageType` as `NORMAL / FIFO / DELAY / TRANSACTION / LITE
(轻量主题消息)`, `ListTopicsResponseBody.List.messageType` returns the same
vocabulary, and `AliyunInstanceProvider.createTopic` (`:247`) already forwards
`topic.getType().name()` verbatim - so Studio can *create* a lite topic on
Aliyun (the CSV importer accepts `Type=LITE` at
`web/src/utils/resourceCsvImport.ts:70` and the 导入 button is not vendor-gated
at `web/src/pages/instance/topic.tsx:1613`) and then cannot *see* it as one.
`docs/api-spec.md:744` also documents the response field as `NORMAL / FIFO /
DELAY / TRANSACTION / LITE`, so the Aliyun provider was the one part of the
stack that could not satisfy the published contract.
What the mis-type costs downstream of `toTopicVO` (`:118`):
- the list tag shows 普通消息 even though `TOPIC_TYPE_MAP.LITE`
(`web/src/constants/theme.ts:60`) and `theme.topicLite`
(`web/src/i18n/translations.ts:2268`) already exist in both languages;
- the LiteTopic filter (`topic.tsx:139`, documented at
`docs/api-spec.md:735`) can never match on an Aliyun instance;
- `canSendTestMessage = !isCloudInstance || topic.type === 'NORMAL'`
(`topic.tsx:353`) offers a plain test message against a lite topic, because the
guard keys on the type Studio got wrong;
- CSV export writes `toText(topic.getType())` into the `Type` column
(`instance/topic/MetadataService.java:791`), so an export -> import round trip
silently converts every lite topic into a NORMAL one;
- `rmq.topic.list` reports NORMAL to the model.
**The change** adds the missing case and keeps the fallback for values this
build does not know:
```java
case "LITE":
// Aliyun RocketMQ 5.0 publishes lite topics as a first class message
type
// (messageType=LITE), spelled exactly like TopicType.LITE. ...
return TopicType.LITE;
```
The `default` comment is reworded so it no longer claims parity with
`parseTopicType` for a value the Apache provider does map.
Deliberately out of scope: `topic.tsx:1799` hides the LiteTopic create card
for every cloud instance, while only Tencent rejects `LITE` server-side
(`TencentInstanceProvider.java:1132`). Making that filter vendor-specific is a
product decision about exposing Aliyun LiteTopic creation in the console and
belongs in its own discussion - this PR only stops the read path from
misreporting topics that already exist.
### How Did You Test This Change?
```
cd server
mvn -o -B test
-Dtest=AliyunConverters*Test,AliyunInstanceProviderTest,TencentInstanceProviderTest,RocketMQMetadataProviderTest
Tests run: 141, Failures: 0, Errors: 0, Skipped: 0
BUILD SUCCESS
```
Checkstyle runs in the `validate` phase of this build (`failsOnError=true`,
`includeTestSourceDirectory=true`), so the run also proves the new code and
tests pass `style/rmq_checkstyle.xml`.
Four new tests in `AliyunConvertersTest` (3 -> 7):
- `toTopicTypeShouldMapEveryDocumentedAliyunMessageTypeTest` - each
documented messageType maps to the matching `TopicType`, `LITE` included;
- `toTopicTypeShouldAcceptTheLowerCaseSpellingOfALiteTopicTest` - `lite`
maps to `LITE`, matching the existing `toUpperCase(Locale.ROOT)` normalisation;
- `toTopicTypeShouldFallBackToNormalOnlyForAnUnknownMessageTypeTest` -
`null`, blank and an unrecognised `SCHEDULED` still fall back to `NORMAL`, so
the read paths keep their never-null guarantee;
- `toTopicVoShouldKeepALiteTopicTypeTest` - the `ListTopics` row conversion
end to end.
Mutation-checked: deleting the new `case "LITE"` makes `mvn -o -B test
-Dtest=AliyunConvertersTest` report `Tests run: 7, Failures: 3` - exactly the
three LITE assertions - while the unknown-value fallback test stays green, so
the new assertions are the ones pinning the behaviour.
### Checklist
- [x] One coherent change; unrelated modifications are not bundled in
- [x] Commit subject follows Conventional Commits (`feat:` / `fix:` /
`refactor:` / `chore:` / `docs:` / `perf:`)
- [x] Tests added or updated for non-trivial changes, test methods named
`...Test`
- [x] New UI text has both Chinese and English entries under `web/src/i18n/`
(no new UI text; `theme.topicLite` already carries both)
- [x] Architecture constraints stay green (`mvn test` runs the ArchUnit
checks)
- [x] New source files carry the ASF license header (no new source files)
- [x] Documentation touched where behaviour changed (README / `docs/` /
in-app help) - none needed; `docs/api-spec.md:744` already promises `LITE`, and
this change is what makes the Aliyun provider honour it
--
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]
