RockteMQ-AI commented on issue #4582:
URL:
https://github.com/apache/rocketmq-dashboard/issues/4582#issuecomment-5748307416
**Issue Evaluation**
Category: `bug` | Status: **Confirmed**
The reported issue has been verified against the current codebase (commit
d50ffecc).
**Root Cause:** In `RocketMQAdminClientImpl.updateTopic` (lines 365-368),
the queue count logic uses `topic.getWriteQueues() > 0` to decide whether to
apply the user's value:
```java
int writeQueues = topic.getWriteQueues() > 0
? topic.getWriteQueues()
: existing != null && existing.getWriteQueueNums() != null
&& existing.getWriteQueueNums() > 0 ?
existing.getWriteQueueNums() : 8;
```
When a user explicitly sends `writeQueues=0`, the condition `> 0` is false,
so the code falls through to the existing value or default 8. The system cannot
distinguish between:
1. User explicitly sent `writeQueues=0` (intends to stop producers)
2. User omitted `writeQueues` (intends to keep current value)
**Impact:** Operators cannot use `writeQueues=0` to temporarily disable
message production to a topic. The zero value is silently replaced with the
existing queue count or default 8.
**Severity:** High — This is a functional bug that prevents a legitimate
operational use case (temporarily stopping producers by setting write queues to
0).
**Fix:** Change `TopicVO.writeQueues` and `readQueues` from primitive `int`
to `Integer` wrapper type, then check for `null` instead of `> 0` in the update
logic. This allows distinguishing between "not provided" (null) and "explicitly
set to 0".
The reporter mentions having a PR ready.
---
*Automated evaluation by @RockteMQ-AI*
--
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]
