Frun1na opened a new issue, #6525: URL: https://github.com/apache/rocketmq-dashboard/issues/6525
### 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 `rocketmq-studio` branch, or I have stated the exact version I am running below. ### Studio Version branch: `rocketmq-studio` git commit id: `779b8c0e` deployed as: reproduced with stubbed Tencent/Aliyun SDK clients in unit tests against that commit ### Runtime Environment OS: Ubuntu on WSL2 MySQL: not applicable — the defect is in the cloud provider topic-update path browser (for UI issues): not applicable ### Connected RocketMQ Cluster RocketMQ version: not applicable — reproduced with stubbed Trocket v20230308 and alibabacloud-rocketmq20220801 clients access mode: Tencent Cloud TDMQ RocketMQ 5.x and ApsaraMQ for RocketMQ 5.x OpenAPI deployment: cloud-managed instances, exercised through `TencentClientFactory` / `AliyunClientFactory` stubs ### Describe the Bug A topic update that asks for properties the vendor API cannot change is accepted, forwarded without those properties, and answered with the requested values: - `AliyunInstanceProvider.updateTopic` (`server/.../provider/alibaba/AliyunInstanceProvider.java:265-278`) builds an `UpdateTopicRequest` with only `topicName` and `remark` and then returns the caller's VO unchanged, so a requested `writeQueues`/`readQueues`/`perm` is echoed as applied. The Aliyun SDK model has no such fields at all: `CreateTopicRequest` carries `instanceId`, `topicName`, `liteTopicExpiration`, `maxSendTps`, `messageType`, `remark` and `UpdateTopicRequest` carries `instanceId`, `topicName`, `liteTopicExpiration`, `maxSendTps`, `remark` (checked against `alibabacloud-rocketmq20220801:5.0.8`), and `AliyunConverters.toTopicVO` reports zero queues and `RW` on the read path. - `TencentInstanceProvider.updateTopic` (`server/.../provider/tencent/TencentInstanceProvider.java:370-391`) sends the queue count but has no permission field in `ModifyTopicRequest` (`instanceId`, `topic`, `queueNum`, `remark`, `msgTTL`, `autoExpireDelete`, `autoExpireTime`), so `perm` is dropped and echoed back; the Tencent read path always reports `RW`. The console's topic edit dialog sends the topic's current values together with the changed ones (`web/src/pages/instance/topic.tsx:1282-1290`), and the AI tool merges the input over the current topic (`TopicUpdateInput.mergeWith`), so a remark-only update keeps working while a queue-count or permission change reports success without changing anything in the cloud. ### Steps to Reproduce The defect is pinned by unit tests; no live cloud account is needed: ``` cd server mvn -B -ntp test -DforkCount=1 -Dtest=AliyunInstanceProviderTest,TencentInstanceProviderTest ``` `updateTopicShouldRejectQueueCountsTheVendorCannotApplyTest` and `updateTopicShouldRejectAPermissionTheVendorCannotApplyTest` (Aliyun) plus `updateTopicShouldRejectAPermissionTheVendorCannotApplyTest` (Tencent) call `updateTopic` with `writeQueues=4` / `perm=RO` and assert a `400` with no SDK interaction. Before the fix all three fail with `Expecting code to raise a throwable.`; `updateTopicShouldStillSendARemarkOnlyUpdateTest` is the control that keeps the ordinary remark update working. ### What Did You Expect to See? An update that requests a property the vendor cannot change should be rejected before the SDK call — `400` with a message naming the limitation, the way the provider already rejects other operations it cannot perform (`TencentInstanceProvider.createTopic` rejects `LITE`, `InstanceProvider.updateConsumerGroup` answers `501`) — instead of returning those values as if they had been applied. ### What Did You See Instead? `updateTopic` reports the requested queue counts and permission back to the caller (and to the AI tool's `after`/`result`), so the console and the assistant present a change that never reached the cloud; only a later read shows the previous state. ### Additional Context A fix with regression tests follows in a pull request. The create path is deliberately unchanged: the console's create dialog always sends its `8/8` defaults, which the Aliyun API ignores by design. -- 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]
