Frun1na opened a new pull request, #6526: URL: https://github.com/apache/rocketmq-dashboard/pull/6526
### Which Issue(s) This PR Fixes - Fixes #6525 ### Brief Description Both cloud providers accepted a topic update that asked for properties their vendor API cannot change and echoed the requested values back as if they had been applied. Aliyun's `CreateTopicRequest`/`UpdateTopicRequest` carry no queue-count and no permission field (`instanceId`, `topicName`, `liteTopicExpiration`, `maxSendTps`, `messageType`, `remark`), so `AliyunInstanceProvider.updateTopic:265-278` sent only the remark and returned the incoming VO unchanged; Tencent's `ModifyTopicRequest` carries `queueNum` but no permission, so `TencentInstanceProvider.updateTopic` dropped `perm` and reported it anyway, and both read paths report every cloud topic as read-write. `AliyunInstanceProvider.updateTopic` now runs `requireUpdatableFields` (400 for positive queue counts, 400 for a permission other than `RW`) and `TencentInstanceProvider.validateUpdateTopic` rejects a permission other than `RW` before the SDK call. User-visible change: the console's queue-count/permission editor and `rmq .topic.update --write-queues/--perm` on a cloud instance now answer `400` with the vendor limitation instead of reporting a change that never reached the cloud; a remark-only update (what the dialog sends when only the remark is edited) is unchanged. The create path is deliberately untouched — the console's create dialog always sends its `8/8` defaults, which the Aliyun API ignores by design. ### How Did You Test This Change? ``` cd server mvn -B -ntp test -DforkCount=1 -Dtest=AliyunInstanceProviderTest,TencentInstanceProviderTest [INFO] Tests run: 56, Failures: 0, Errors: 0, Skipped: 0 -- in ...TencentInstanceProviderTest [INFO] Tests run: 44, Failures: 0, Errors: 0, Skipped: 0 -- in ...AliyunInstanceProviderTest [INFO] Tests run: 100, Failures: 0, Errors: 0, Skipped: 0 [INFO] You have 0 Checkstyle violations. ``` The three new cases fail without the fix (`updateTopicShouldRejectQueueCountsTheVendorCannotApplyTest` and `updateTopicShouldRejectAPermissionTheVendorCannotApplyTest` for Aliyun, one for Tencent; each asserts the 400 and `verifyNoInteractions` on the client factory), while `updateTopicShouldStillSendARemarkOnlyUpdateTest` keeps the ordinary update pinned: ``` [ERROR] Tests run: 100, Failures: 3, Errors: 0, Skipped: 0 ...updateTopicShouldRejectQueueCountsTheVendorCannotApplyTest -- FAILURE! java.lang.AssertionError: Expecting code to raise a throwable. ...updateTopicShouldRejectAPermissionTheVendorCannotApplyTest -- FAILURE! (Aliyun) java.lang.AssertionError: Expecting code to raise a throwable. ...updateTopicShouldRejectAPermissionTheVendorCannotApplyTest -- FAILURE! (Tencent) java.lang.AssertionError: Expecting code to raise a throwable. ``` Reverting only the three guards (both helpers and the Tencent check) reproduces exactly those three failures, so the assertions are sensitive to the fix. ### Checklist - [x] One coherent change; unrelated modifications are not bundled in - [x] Commit subject follows Conventional Commits (`feat:` / `fix:` / `refactor:` / `chore:` / `docs:` / `perf:`) - [x] Tests added or updated for non-trivial changes, test methods named `...Test` - [ ] New UI text has both Chinese and English entries under `web/src/i18n/` - [ ] Architecture constraints stay green (`mvn test` runs the ArchUnit checks) - [ ] New source files carry the ASF license header - [ ] Documentation touched where behaviour changed (README / `docs/` / in-app help) -- 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]
