Frun1na opened a new pull request, #6548:
URL: https://github.com/apache/rocketmq-dashboard/pull/6548
### Which Issue(s) This PR Fixes
- Fixes #6547
### Brief Description
The group-create contract carries `ConsumerGroupVO.consumeType`, the AI
tool's create input offers it
(`tool-catalog/tools/group.yaml`), and both responses echo the submitted VO
— but neither cloud adapter applied
the requested model, so a caller could be told a group is broadcast while
the vendor created a clustering one and
the next list read showed the vendor's real model (Aliyun:
`AliyunConverters.toConsumeType(data.getMessageModel())`,
`AliyunConverters.java:179`; Tencent:
`enrichConsumerGroupDetail`, `TencentInstanceProvider.java:483-497`). #4816
fixed the same silent downgrade for
Aliyun's delivery order type in this very method.
- **Aliyun applies it now**: `AliyunInstanceProvider.createConsumerGroup`
(`:369-377`) carries
`messageModel = Broadcasting` for a requested broadcast, using the
vendor's own spelling through a new
`AliyunConverters.toMessageModel` that sits next to the read-side inverse.
An unspecified or clustering model
keeps the field out of the payload, so the default path stays
byte-identical.
- **Tencent rejects it now**: `CreateConsumerGroupRequest` has no
consume-model field (verified with `javap`
against `tencentcloud-sdk-java-trocket-3.1.1498`: only instanceId,
consumerGroup, maxRetryTimes, consumeEnable,
consumeMessageOrderly, remark, tagList, retryPolicy, liteTopic), so
`validateConsumerGroup` answers
`400 Tencent consumer groups always consume in clustering mode;
consumeType BROADCASTING cannot be applied`
before any SDK call — the answer `InstanceProvider#updateConsumerGroup`'s
contract asks for, and the same shape
#5652 / #6173 / #6526 use for a vendor limitation.
- **The accepted fields stay applied**: Aliyun still sends the retry policy
and delivery order type, Tencent still
sends `maxRetryTimes` / `consumeMessageOrderly` / `consumeEnable`; the
guard sits in `validateConsumerGroup`, so
the import path (which defaults to create) is covered as well.
User-visible change: an `rmq.group.create` tool call or API request for
`consumeType = BROADCASTING` on Aliyun now
creates a broadcast group, and on Tencent it answers `400` naming the
limitation instead of reporting a change the
OpenAPI cannot make. The console is unaffected — it hides the consume-type
radio for cloud instances
(`web/src/pages/instance/consumer.tsx:2448`).
### How Did You Test This Change?
```
cd server && mvn -B -ntp test -DforkCount=1
-Dsurefire.failIfNoSpecifiedTests=false
-Dtest=AliyunInstanceProviderTest,TencentInstanceProviderTest
[INFO] Tests run: 43, Failures: 0, Errors: 0, Skipped: 0 -- in
AliyunInstanceProviderTest
[INFO] Tests run: 57, Failures: 0, Errors: 0, Skipped: 0 -- in
TencentInstanceProviderTest
[INFO] BUILD SUCCESS
```
`createConsumerGroupShouldApplyTheRequestedBroadcastingModelTest` captures
the Aliyun request and asserts
`getMessageModel() == "Broadcasting"` plus the echoed VO;
`createConsumerGroupShouldLeaveTheConsumeModelToTheVendorWhenClusteringTest`
is the control that a clustering request still sends no model;
`createConsumerGroupShouldRejectABroadcastingModelTheOpenApiCannotApplyTest`
asserts the Tencent 400 and
`verifyNoInteractions(client)`;
`createConsumerGroupShouldStillApplyTheOrderedAndRetrySettingsTest` is the
control
that an ordered Tencent create still carries `consumeMessageOrderly = true`,
`maxRetryTimes = 20` and
`consumeEnable = true`.
The two new assertions fail without the fix — only the three product changes
reverted, the tests kept:
```
[ERROR] Tests run: 43, Failures: 1 -- in AliyunInstanceProviderTest
createConsumerGroupShouldApplyTheRequestedBroadcastingModelTest -- <<<
FAILURE!
org.opentest4j.AssertionFailedError:
expected: "Broadcasting"
but was: null
[ERROR] Tests run: 57, Failures: 1 -- in TencentInstanceProviderTest
createConsumerGroupShouldRejectABroadcastingModelTheOpenApiCannotApplyTest
-- <<< FAILURE!
java.lang.AssertionError:
Expecting code to raise a throwable.
```
Each failure names exactly the value the fix changes (the missing request
field, the missing rejection), and both
control tests keep passing in the same runs.
### 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`
- [ ] New UI text has both Chinese and English entries under `web/src/i18n/`
- [ ] Architecture constraints stay green (`mvn test` runs the ArchUnit
checks)
- [ ] New source files carry the ASF license header
- [ ] Documentation touched where behaviour changed (README / `docs/` /
in-app help)
--
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]
