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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
