zmuxuny opened a new issue, #6626: URL: https://github.com/apache/rocketmq-dashboard/issues/6626
### 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 rocketmq-studio @ 779b8c0e7aed2396d3cc72743dcd544ea48e9ae6 ### Runtime Environment Linux x86_64; deterministic RocketMQAdminClientImpl regression tests. ### Connected RocketMQ Cluster Apache RocketMQ 5.5.0 client APIs. Existing topic configuration responses and update RPCs are mocked; no live production cluster changed. ### Build Toolchain JDK 21, Maven 3.9.11, existing project test/checkstyle configuration. ### Describe the Bug Updating an existing topic through Studio constructs a new TopicConfig and assigns only editable request fields. Existing broker-specific topicSysFlag, order and topicFilterType values are replaced with constructor defaults, although the operator did not edit those fields. A queue-count or remark change can therefore clear unit-topic flags or other existing topic behavior. ### Steps to Reproduce 1. Return an existing topic configuration with non-default topicSysFlag, order and topicFilterType from a target master. 2. Call the real updateTopic path with an ordinary queue-count/permission/remark edit. 3. Capture the TopicConfig sent to createAndUpdateTopicConfig and compare the unedited fields. 4. Also cover multiple masters with different existing flags, plus a read failure on a later master before any update is attempted. Against unchanged production code the field-preservation assertion fails (topicSysFlag expected 2, got 0). Existing controls pass. ### What Did You Expect to See? Preserve each existing master configuration field that Studio does not expose for editing. Pre-read target configurations before writing so an actual read/RPC failure cannot produce a partial update with unknown defaults. Confirmed topic absence on a new master should retain the existing provisioning behavior. ### What Did You See Instead? The outgoing config resets unedited flags to defaults. No configuration preflight is performed, so it cannot preserve broker-specific settings or stop before writes when a configuration read would fail. ### Additional Context RocketMQ applies the requested TopicConfig as a replacement while merging attribute deltas: https://github.com/apache/rocketmq/blob/rocketmq-all-5.5.0/broker/src/main/java/org/apache/rocketmq/broker/topic/TopicConfigManager.java#L522-L545 . Request field assignment: https://github.com/apache/rocketmq/blob/rocketmq-all-5.5.0/broker/src/main/java/org/apache/rocketmq/broker/processor/AdminBrokerProcessor.java#L578-L585 . Preserve attribute delta semantics rather than replaying the entire existing attribute map. Searched current issues/PRs for topicSysFlag, topicFilterType and unit-topic flags; topology mapping and legacy ordered-topic UI reports address different paths. ### 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]
