Frun1na opened a new issue, #6547: URL: https://github.com/apache/rocketmq-dashboard/issues/6547
### 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, or I have stated the exact version I am running below. ### Studio Version branch: `rocketmq-studio` git commit id: `779b8c0e` deployed as: reproduced by unit tests against that commit (cloud SDKs are stubbed, the requests they receive are asserted) ### Runtime Environment OS: Ubuntu on WSL2 MySQL: not applicable — the defect is a dropped request field and a missing rejection in the cloud adapters browser: not applicable — reproduced in JUnit 5 provider tests ### Connected RocketMQ Cluster RocketMQ version: not applicable — the vendor OpenAPI request is built in-process; the unit tests stub the SDK client and assert the request object access mode: not applicable deployment: not applicable ### Describe the Bug The consumer-group create contract carries `ConsumerGroupVO.consumeType` (`CLUSTERING` / `BROADCASTING`), the AI tool's create input offers it (`tool-catalog/tools/group.yaml`, `consumeType`), and the controller and tool responses echo the submitted VO — but neither cloud adapter applies the requested model, so the caller is told the group is broadcast while the vendor creates a clustering one: - `AliyunInstanceProvider.createConsumerGroup` (`server/src/main/java/org/apache/rocketmq/studio/provider/alibaba/AliyunInstanceProvider.java:369-377`) builds the request without `messageModel`, although `CreateConsumerGroupRequest` has that field (verified with `javap` against `alibabacloud-rocketmq20220801-5.0.8`). The group page then reads the real model back through `AliyunConverters.toConsumeType(data.getMessageModel())` (`AliyunConverters.java:179`), so the requested broadcast silently turns into clustering on the next refresh. - `TencentInstanceProvider.createConsumerGroup` cannot apply it at all: `CreateConsumerGroupRequest` (tencentcloud-sdk-java-trocket-3.1.1498) has no consume-model field — only `instanceId`, `consumerGroup`, `maxRetryTimes`, `consumeEnable`, `consumeMessageOrderly`, `remark`, `tagList`, `retryPolicy`, `liteTopic` — while `enrichConsumerGroupDetail` (`TencentInstanceProvider.java:483-497`) reports `DescribeConsumerGroup.consumeModel`, so the same downgrade surfaces on the next list refresh. The trigger is the tool/API path, not the console: the console hides the consume-type radio for cloud instances (`web/src/pages/instance/consumer.tsx:2448`, `!isCloudInstance`), but an `rmq.group.create` tool call or any API caller can send `consumeType`, and the CSV/JSON import path goes through the same provider method. ### Steps to Reproduce 1. `POST /api/consumer-groups/create` (or an `rmq.group.create` tool call) with `{"instanceId":"<aliyun instance>","name":"GID_broadcast","consumeType":"BROADCASTING"}`: the response reports `consumeType: BROADCASTING`, but the group list/detail then reports `CLUSTERING` (the vendor's real `messageModel`). 2. The same on a Tencent instance: the create is answered successfully with `BROADCASTING` while `DescribeConsumerGroup.consumeModel` reports the vendor's clustering model. 3. Without cloud access: `AliyunInstanceProviderTest.createConsumerGroupShouldApplyTheRequestedBroadcastingModelTest` and `TencentInstanceProviderTest.createConsumerGroupShouldRejectABroadcastingModelTheOpenApiCannotApplyTest` drive `createConsumerGroup` over the stubbed SDK client and assert the request object / the rejection. ### What Did You Expect to See? The requested model either reaches the vendor or the request is refused, never silently downgraded and echoed: - Aliyun applies it — the request carries `messageModel = Broadcasting` (the vendor's spelling, the one the read path recognises), so the group really is broadcast and the response is truthful. - Tencent, whose create request has no such field, answers `400` before any SDK call — the same answer `InstanceProvider#updateConsumerGroup`'s contract asks for ("a provider that cannot apply a change must reject the request rather than report success"), and the same shape #5652 / #6173 / #6526 use. - The fields the vendor APIs *do* accept stay applied: `maxRetryTimes`, `consumeMessageOrderly`, `deliveryOrderType` on Tencent, the retry policy and delivery order type on Aliyun, and a clustering or unspecified request keeps the Aliyun payload byte-identical. ### What Did You See Instead? Both adapters answered successfully and echoed `consumeType: BROADCASTING`; Aliyun sent no `messageModel` at all and Tencent sent nothing it could not apply, so the created groups stayed clustering and only the follow-up read revealed the difference. ### Additional Context A fix with regression tests follows in a pull request. #4816 fixed the same silent downgrade for Aliyun's delivery order type on this very method. ### 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]
