unbridled-41 opened a new issue, #5923:
URL: https://github.com/apache/rocketmq-dashboard/issues/5923

   ### Studio Version
   branch: `rocketmq-studio` @ `7e7aa344` (the revision verified; the branch is 
based on it)
   deployed as: not required to reproduce
   
   ### Runtime Environment
   
   Reproduced with the backend tests (`cd server && mvn -o -B -ntp test 
-Dtest='RocketMQAdminClientImplTest'`); no cluster needed.
   
   ### Connected RocketMQ Cluster
   
   Any cluster whose topic/group exists on some broker groups but not on others 
- the normal state after a broker group is added.
   
   ### Describe the Bug
   
   `verifyTopicImport` reported one boolean for the whole cluster and the 
caller read it as "nothing to do":
   
   ```java
   // RocketMQAdminClientImpl (before)
   boolean physicalExists = importing && verifyTopicImport(admin, brokerAddrs, 
topicConfig);
   if (!physicalExists) {
       for (String addr : brokerAddrs) { admin.createAndUpdateTopicConfig(addr, 
topicConfig); }
   }
   ```
   
   `verifyTopicImport` set `found = true` as soon as **any** master held a 
matching config, so an import where the topic exists on the old broker group 
and is missing on a newly added one created nothing anywhere, marked the 
metadata row ACTIVE and reported success (the controller answers `imported=N, 
failed=0`). With `autoCreateTopicEnable` at its RocketMQ default, the new 
broker later serves the topic auto-created with factory defaults, silently 
without the imported queue counts, permission or message type. 
`verifyGroupImport` had the same shape for consumer groups.
   
   ### Steps to Reproduce
   
   1. Create a topic on a cluster, then add a second broker group to it (that 
group has none of the user topics).
   2. Re-import the exported topic inventory to propagate it.
   3. `imported` counts the row, but `examineTopicConfig` on the new master 
still reports TOPIC_NOT_EXIST; the topic is later auto-created with default 
queue counts.
   
   ### What Did You Expect to See?
   
   The import creates the topic on every master that does not have a matching 
config yet.
   
   ### What Did You See Instead?
   
   Nothing was created, and the response said the import succeeded.
   
   ### Evidence
   
   - `server/.../provider/apache/RocketMQAdminClientImpl.java` (the import 
gate, `verifyTopicImport`, `verifyGroupImport`), 
`server/.../instance/MetadataService.java` (`importTopics`), 
`server/.../instance/topic/TopicController.java`.
   - `cd server && mvn -o -B -ntp test 
-Dtest='RocketMQAdminClientImplTest#importTopicCreatesTheTopicOnTheMastersThatLackItTest'`
 - before the fix the test fails with "Wanted but not invoked: 
createAndUpdateTopicConfig(\"10.0.0.2:10911\")".
   
   ### Impact
   
   A silently half-configured cluster after a broker-group addition, reported 
as a successful import; the operator only notices when the auto-created topic 
loses the exported configuration.
   
   ### Acceptance Criteria
   
   - An import writes to exactly the masters that lack a matching config, still 
refuses a conflicting one with 409, with regression tests for topics and groups.
   
   **Corresponding PR:** #ISSUEPR#
   


-- 
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]

Reply via email to