Frun1na opened a new issue, #4582: URL: https://github.com/apache/rocketmq-dashboard/issues/4582
### Before Creating the Bug Report - [x] I have searched the [open issues](https://github.com/apache/rocketmq-dashboard/issues) of this repository and believe that this is not a duplicate. - [x] This is a defect in RocketMQ Studio, not a usage question and not a defect in another Apache RocketMQ repository. - [x] I can reproduce this on the current `master` branch, or I have stated the exact version I am running below. ### Studio Version branch: master git commit id: d50ffecc deployed as: built from source ### Runtime Environment OS: Ubuntu 24.04 (WSL2) MySQL: 8.x, container from deploy/docker-compose.yml browser: not applicable (API-level defect) ### Connected RocketMQ Cluster Not applicable: reproduced with a unit test (`RocketMQAdminClientImplTest`) on master, where `DefaultMQAdminExt` is mocked. The defect is in the update path itself, before any cluster call. ### Build Toolchain _No response_ ### Describe the Bug `POST /api/topics/update` (and the `rmq.topic.update` AI tool) silently ignores an explicit `writeQueues: 0`. A write-queue count of 0 is a legitimate way to stop producers while consumers drain a topic, but the request behaves exactly like omitting the field: the stored queue count (or the default of 8) is applied instead. Root cause: `TopicVO` declares `writeQueues`/`readQueues` as primitive `int`, so once `UpdateTopicDTO.toTopicVO()` / `TopicUpdateInput.mergeWith()` copy the value, an explicit 0 and an omitted field are indistinguishable. `RocketMQAdminClientImpl.updateTopic` then uses a `> 0` check to mean "not provided". ### Steps to Reproduce 1. On master, run the (new) unit test `RocketMQAdminClientImplTest.updateTopicAppliesExplicitZeroQueueCounts`, or: 2. Call `POST /api/topics/update` for an existing 8/8 topic with body `{"instanceId": "...", "name": "orders", "writeQueues": 0, "readQueues": 8}`. 3. The broker config and the stored metadata keep `writeQueueNums: 8`; the response also reports 8. ### What Did You Expect to See? An explicit `writeQueues: 0` is applied to the broker topic config and the stored metadata. An omitted value continues to preserve the stored count (the fix for #4123/#4275 already established "absent keeps the stored value"). ### What Did You See Instead? `writeQueues: 0` is treated as "not provided" and silently replaced with the previous value or the default of 8. ### Additional Context Suggested direction: make the two `TopicVO` fields nullable (`Integer`), mirroring the optional semantics `perm` already uses, and let the Apache update path apply an explicit 0. I have a failing-test-first patch ready and will link the PR here shortly. ### Are You Willing to Submit a Pull Request? - [x] Yes, I am willing to submit a pull request. -- 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]
