unbridled-41 opened a new issue, #5929:
URL: https://github.com/apache/rocketmq-dashboard/issues/5929
### Studio Version
branch: `rocketmq-studio` @ `7e7aa344` (the revision verified; the branch is
based on it)
deployed as: not required to reproduce
### Runtime Environment
Reproduced with the backend tests (`cd server && mvn -o -B -ntp test
-Dtest='RocketMQAdminClientImplTest'`).
### Connected RocketMQ Cluster
Any cluster where the create endpoint is called for a group that already
exists on the broker.
### Describe the Bug
The create path always writes a freshly built `SubscriptionGroupConfig` with
the creation defaults:
```java
config.setConsumeEnable(true);
config.setConsumeBroadcastEnable(true);
config.setRetryQueueNums(1);
...
boolean physicalExists = importing && verifyGroupImport(admin, brokerAddrs,
config);
if (!physicalExists) { for (String addr : brokerAddrs) {
admin.createAndUpdateSubscriptionGroupConfig(addr, config); } }
```
`importing` is false for every REST and AI call, so creating a group that
already exists on that broker resets the settings the request never mentions:
`retryQueueNums` back to 1, consumption re-enabled, broadcast consumption
re-enabled, ordered consumption back to concurrent. That happens on a
resubmitted create form and is the normal path for the AI upsert, which calls
create whenever the metadata table has no row - including for a group that
exists physically but was never imported. Meanwhile the documented update path
reads every broker first and mutates only the requested field ("Preserve each
broker's other settings; zero is an explicit retry limit").
### Steps to Reproduce
1. Create a group, then set its retry queue count to 5 and disable
consumption via the group settings.
2. POST the same group to `/api/groups/create` again (or let the AI upsert
run for it).
3. The broker config is back to `retryQueueNums=1`, `consumeEnable=true`; an
ordered group returns to concurrent consumption.
### What Did You Expect to See?
A create for an existing group applies what the request carries and leaves
the rest alone.
### What Did You See Instead?
The group's live settings were reset to the creation defaults, silently, and
the endpoint answered 200.
### Evidence
- `server/.../provider/apache/RocketMQAdminClientImpl.java` (create path vs
`updateConsumerGroup`'s read-then-mutate loop).
- `cd server && mvn -o -B -ntp test
-Dtest='RocketMQAdminClientImplTest#createConsumerGroupKeepsTheExistingBrokerSettingsOfAnAlreadyPresentGroupTest'`
- before the fix `retryQueueNums` is expected 5 but 1.
### Impact
Silent corruption of a live consumer group's broker configuration (retry
queue count, consumption switches, ordered consumption), reachable from a
resubmitted form or the AI upsert.
### Acceptance Criteria
- A create for a group that already exists on a master preserves every
setting the request does not carry, still applies the retry limit and an
explicitly requested delivery order type, and absent groups keep the creation
defaults, with a regression test.
**Corresponding PR:** #ISSUEPR#
--
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]
