Wang1rrr opened a new issue, #4838: URL: https://github.com/apache/rocketmq-dashboard/issues/4838
### 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 provider-side, so the host does not matter MySQL: not required - reproduced at the provider layer against a mocked MQAdminExt browser (for UI issues): any; the console form that submits the field is web/src/pages/instance/consumer.tsx ``` ### Connected RocketMQ Cluster ``` RocketMQ version: 5.x, self-managed (the Apache provider) access mode: Direct to NameServer/Broker deployment: any - the field is dropped inside Studio before it reaches the broker ``` ### Describe the Bug The console's create-consumer-group form offers a delivery order type (顺序类型) whenever the subscription data type is FIFO, and submits it as `PARTITON_ORDER` (分区顺序, the form's own default) or `MESSAGES_ORDER` (全局顺序): - `web/src/pages/instance/consumer.tsx:2441` - the `Form.Item name="deliveryOrderType"` with `initialValue="PARTITON_ORDER"` - `web/src/pages/instance/consumer.tsx:2348` - `deliveryOrderType: values.deliveryOrderType` in the create payload - `CreateConsumerGroupDTO.java:34` / `:50` - the field is copied into `ConsumerGroupVO` - `ConsumerGroupVO.java:42` - `private String deliveryOrderType;` Both cloud providers act on it: - Aliyun: `AliyunInstanceProvider.normalizeDeliveryOrderType` (`:381`) maps the ordered spellings to `Orderly` before calling OpenAPI. - Tencent: `TencentInstanceProvider.isOrderly` (`:1056`) feeds `request.setConsumeMessageOrderly(...)` (`:503`). The Apache provider - the path every self-managed cluster takes - never reads the field. `RocketMQAdminClientImpl.createConsumerGroup(MQAdminExt, ConsumerGroupVO)` (`:738`) builds a fresh `SubscriptionGroupConfig` and sets exactly five properties: `groupName`, `consumeEnable`, `consumeBroadcastEnable`, `retryQueueNums`, `retryMaxTimes`. `consumeMessageOrderly` keeps its `false` default, and `persistConsumerGroup` (`:772`) cannot record the choice either, because `RmqGroup` has no such column (`persistence/entity/RmqGroup.java:31-51`). The result is that the value is accepted, echoed straight back in the HTTP response (the controller returns the submitted VO), and then discarded: an ordered group is created unordered, with no warning anywhere. This is not a missing concept in Studio - the same flag is already a first-class, editable group setting: - `RocketMQAdminClientImpl.java:648` reads `config.isConsumeMessageOrderly()` into `ConsumerGroupSettingsVO` - `RocketMQAdminClientImpl.java:689` writes it back from `ConsumerGroupSettingsCommand` So Studio has two UI surfaces for one intent, and the create surface is wired to neither. An operator who asks for 分区顺序 at creation time has to notice the mistake and flip it afterwards in the settings dialog. Two more callers lose the value the same way, since they go through the same provider method: - the AI tool path: `GroupInput.java:38` sets `deliveryOrderType` on the VO it hands to `createConsumerGroup` - the CSV importer: `web/src/utils/resourceCsvImport.ts:376` emits `deliveryOrderType` for FIFO rows, and validates it against `PARTITON_ORDER` / `PARTITION_ORDER` / `MESSAGES_ORDER` (`:75`) ### Steps to Reproduce 1. Point Studio at a self-managed RocketMQ cluster (Apache provider, direct to NameServer/Broker). 2. Console -> Consumer Group -> 新建消费组. Set 订阅组类型 = 顺序消息 (FIFO) so the 顺序类型 selector appears, leave it at its default 分区顺序 (`PARTITON_ORDER`), and submit. 3. Open the new group's 设置 dialog (or run `mqadmin examineSubscriptionGroupConfig -g <group>`). ### What Did You Expect to See? 顺序消费 / `consumeMessageOrderly` = `true` on the created subscription group, matching the delivery order type that was submitted, and matching what the Aliyun and Tencent providers do with the same field. ### What Did You See Instead? `consumeMessageOrderly` = `false`. The create call reports success, the response echoes `deliveryOrderType: "PARTITON_ORDER"` back to the browser, and the broker holds an unordered group. The `CREATE_GROUP` audit record only mentions `retryMaxTimes`, so there is no trace of the dropped choice either. ### Additional Context Suggested fix, and the one in the pull request I am about to open: derive `consumeMessageOrderly` from `group.getDeliveryOrderType()` in the create path using the vocabulary `TencentInstanceProvider.isOrderly` already accepts (`FIFO` or `ORDER` as a case-insensitive substring, which covers `PARTITON_ORDER`, `PARTITION_ORDER`, `MESSAGES_ORDER`, `FIFO`, `ORDERLY` and leaves `Concurrently`/absent as unordered), and add the resolved flag to the `CREATE_GROUP` audit detail so the decision is traceable. A wider question worth a separate discussion: `subscriptionDataType` is dropped by the same create path for the same reason (`RmqGroup` has no column), so an Apache-backed group also loses its FIFO/DELAY/TRANSACTION classification. That one needs a schema change, so it is deliberately out of scope here. ### 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]
