Wang1rrr opened a new pull request, #4920: URL: https://github.com/apache/rocketmq-dashboard/pull/4920
## What is the purpose of the change The create-consumer-group form exposes an "顺序类型" (delivery order type) select when the message type is FIFO, with the values `PARTITON_ORDER` (partition order) and `MESSAGES_ORDER` (message order) (`web/src/pages/instance/consumer.tsx`), and submits the chosen value as `deliveryOrderType`. `AliyunInstanceProvider.normalizeDeliveryOrderType` only mapped `FIFO` and `ORDERLY` to the Aliyun OpenAPI value `Orderly`; everything else fell back to `Concurrently`. As a result, a user selecting either ordered option for an Aliyun group silently created a concurrently-delivered group — the UI choice was discarded at the provider boundary. This extends the normalizer so any value containing `ORDER` (case-insensitive) maps to `Orderly`, alongside the existing `FIFO` / `ORDERLY` aliases. `Concurrently` is unaffected. The regression test now covers `PARTITON_ORDER` and `MESSAGES_ORDER` in addition to the existing cases. ## Brief changelog - `AliyunInstanceProvider.normalizeDeliveryOrderType` maps the create-form values to `Orderly`. - `AliyunInstanceProviderTest#normalizeDeliveryOrderTypeShouldMapFifoToOrderlyTest` covers both front-end values. ## Verifying this change `mvn -f server/pom.xml test -Dtest='AliyunInstanceProviderTest'` Tests run: 35, Failures: 0, Errors: 0 (checkstyle runs at validate and also passes). The two new assertions fail on trunk, which returns `Concurrently` for both values. -- 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]
