The GitHub Actions job "CI" on rocketmq-dashboard.git/fix/cloud-group-consume-model has succeeded. Run started by GitHub user Frun1na (triggered by Frun1na).
Head commit for run: 0fe591d2ff269bda6b2d6d381ff7a670777bed0c / Apulupie <[email protected]> fix(group): apply or reject the consume model of a cloud consumer group The group-create contract carries ConsumerGroupVO.consumeType, and the tool and REST responses echo the submitted VO, but neither cloud adapter applied the requested model. AliyunInstanceProvider.createConsumerGroup never set messageModel even though the OpenAPI request has the field, so a broadcast request created a clustering group; the group page reads the real model back through AliyunConverters.toConsumeType(data.getMessageModel()), so the downgrade surfaced later as an unexplained change. The request now carries the vendor's own spelling for a requested broadcast, while an unspecified or clustering model keeps the field out of the payload exactly as before. TencentInstanceProvider.createConsumerGroup cannot apply it at all: CreateConsumerGroupRequest has no consume-model field (only instanceId, consumerGroup, maxRetryTimes, consumeEnable, consumeMessageOrderly, remark, tagList, retryPolicy, liteTopic), while enrichConsumerGroupDetail reports DescribeConsumerGroup's real consumeModel. validateConsumerGroup now rejects a broadcast request with 400 before any SDK call, which is what InstanceProvider#updateConsumerGroup's contract asks for - never report a change the adapter cannot apply - and both adapters still apply the fields their APIs do accept (maxRetryTimes, consumeMessageOrderly, deliveryOrderType). Report URL: https://github.com/apache/rocketmq-dashboard/actions/runs/38348442279 With regards, GitHub Actions via GitBox
