[I] [Bug] LiteTopic TTL updates can leave broker masters with mixed expiration values [rocketmq-dashboard]

["X-LightYear (via GitHub)" <gi...@apache.org>]

X-LightYear opened a new issue, #7085:
URL: https://github.com/apache/rocketmq-dashboard/issues/7085

   ## Problem
   
   The LiteTopic TTL mutation can leave broker masters with different expiration values when a later broker write fails.
   
   ## Production path
   
   `POST /api/liteTopic/extendTTL` → `LiteTopicController.extendTTL` → `LiteTopicService.extendTTL` → `RocketMQLiteTopicProvider.extendTTL` → `MQAdminExt.createAndUpdateTopicConfig` for each broker master.
   
   ## Reproduction
   
   On Apache RocketMQ Studio commit `127c47b06`, configure an instance with two reachable broker masters and a Lite parent topic `chat` whose expiration is 30 minutes on both masters.
   
   1. Request a TTL extension to 120 minutes.
   2. Let the first broker accept the topic-config update.
   3. Make the next broker write fail, for example with a timeout.
   
   The read preflight succeeds for both brokers, so the failure occurs during the write phase.
   
   ## Expected behavior
   
   A failed multi-broker mutation should not silently leave the cluster in a mixed configuration. The operation should either avoid partial mutation or provide an explicit, recoverable partial-failure result with a defined recovery path.
   
   ## Actual behavior
   
   The request fails after the later write error, but the earlier broker has already been changed. The cluster can therefore contain `lite.topic.expiration=120` on one master and `lite.topic.expiration=30` on another, while the caller receives only the write exception.
   
   ## Root cause
   
   `RocketMQLiteTopicProvider.extendTTL` first reads all broker configs, then iterates over the pending masters and writes each update sequentially. It has no rollback or partial-result handling for a write-phase exception. The existing preflight only prevents partial updates caused by read failures; it does not make the write phase atomic.
   
   ## Regression evidence
   
   Temporary deterministic test:
   
   `RocketMQLiteTopicProviderTest.extendTtlDoesNotLeaveEarlierMastersChangedWhenALaterWriteFails`
   
   Command:
   
   ```text
   mvn.cmd "-Dmaven.repo.local=E:\\Project\\RocketMQ\\.m2repo-discovery3" "-Dtest=RocketMQLiteTopicProviderTest#extendTtlDoesNotLeaveEarlierMastersChangedWhenALaterWriteFails" "-Dmaven.compiler.proc=full" test
   ```
   
   The test fails on the current production code with Mockito `NeverWantedButInvoked`: `createAndUpdateTopicConfig("broker-a:10911", ...)` was invoked at `RocketMQLiteTopicProvider.java:409` before the configured failure for `broker-b:10911`.
   
   ## Scope
   
   The issue is limited to the multi-master LiteTopic TTL mutation write phase. The existing read-preflight behavior and successful all-master update behavior should remain unchanged.
   
   ## Duplicate check
   
   Searched open and closed Issues and PRs using `LiteTopic TTL partial update`, `extendTTL partial broker`, `lite.topic.expiration mixed`, `broker write failure lite topic`, and `litetopic expiration rollback`.
   
   Issue #6643 discusses LiteTopic lifecycle management and states an intended all-master write pattern, but does not report or test a write-phase partial failure. No matching bug report or fix was found.
   


-- 
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: commits-unsubscribe@rocketmq.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org