iloveeyjafjalla opened a new issue, #6862:
URL: https://github.com/apache/rocketmq-dashboard/issues/6862
### Studio Version
branch: `rocketmq-studio` @ `a92c2314`
### Runtime Environment
The repository's own stack: backend on 8888 against its MySQL, the console
on the dev server, one Apache instance (`local-broker`) pointing at a
NameServer that serves a broker on 127.0.0.1:10911 (image
`apache/rocketmq:5.3.2`).
### Connected RocketMQ Cluster
RocketMQ 5.3.2 broker, direct to NameServer (V4_DIRECT).
### Describe the Bug
`POST /api/topics/create` writes the config built from the creation defaults
every time, so calling it for a topic that already exists on the broker resets
every setting the request does not carry. Two live reproductions on the stack
above:
**Queue counts.** `studio-e2e-check` held 6 read / 6 write queues. A create
whose form omitted the queue fields answered `200 success` and the broker's
topic came back with 8 queues:
```
$ mqadmin topicStatus -t studio-e2e-check -n rmq-nameserver:9876 | wc -l
# 6 queue rows
$ curl -X POST .../api/topics/create -d
'{"name":"studio-e2e-check","type":"NORMAL","instanceId":"local-broker"}'
{"code":200,"message":"success",...}
$ mqadmin topicStatus -t studio-e2e-check -n rmq-nameserver:9876 | wc -l
# 8 queue rows
```
**Permission.** A write-only topic is widened to read-write. `ro-probe-1`
was created on the broker with `-p 2` (write only); a create that did not
mention the permission left `"perm":6` in the broker's topic config - a
permission the caller never asked for.
The metadata row is written from the same values, so the console shows the
reset as well, and a resubmitted create form does this without any warning. It
is the same shape as #5929 on the consumer-group path, where a re-create reset
`retryQueueNums` to 1 and re-enabled consumption; that one has #5930 open.
Root cause, in `RocketMQAdminClientImpl#createTopic`:
```java
boolean physicalExists = importing && verifyTopicImport(admin, brokerAddrs,
topicConfig);
if (!physicalExists) {
for (String addr : brokerAddrs) {
admin.createAndUpdateTopicConfig(addr, topicConfig); // creation
defaults, always
}
}
```
`importing` is false for every REST and AI call, so the write always applies
the config built from the request defaults (`writeQueues`/`readQueues` 8 when
omitted, `perm` RW when omitted) instead of what the master already holds.
### Steps to Reproduce
1. Create a topic on the broker outside Studio: `mqadmin updateTopic -t
probe -c DefaultCluster -r 6 -w 6 -p 2 -n <nameserver>`.
2. `curl -X POST .../api/topics/create -d
'{"name":"probe","type":"NORMAL","instanceId":"<instance>"}'` (no queue counts,
no permission).
3. Read the broker's topic config: 8 read / 8 write queues and `perm: 6` -
the live settings were replaced by the creation defaults.
### What Did You Expect to See?
Create adds a topic that is missing and leaves a topic that is already there
alone: every setting the request does not carry keeps the value the master has,
exactly as the group path does after #5930. The unit tests added with the fix
pin the queue counts, the permission and the message type for that case.
### What Did You See Instead?
`200 success` plus a topic rewritten with the creation defaults: 8/8 queues
and RW permission regardless of what the topic had, with no warning in the
console and no hint in the response.
--
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]
