btlqql opened a new pull request, #7137: URL: https://github.com/apache/rocketmq-dashboard/pull/7137
## What is the purpose of the change `RocketMQLiteTopicProvider.extendTTL` reads `lite.topic.expiration` from every broker master that carries the Lite parent topic and then rewrites them one by one. The read preflight keeps a read failure from partially applying the change, but the write phase had no equivalent: when a later `createAndUpdateTopicConfig` failed, the masters written before it already stored the new TTL while the caller only received the raw write error (`RocketMQLiteTopicProvider.java:409`). The cluster could stay split between the old and the new expiration, with nothing in the response saying which masters had changed or how to converge them. The write loop now records the masters it has already updated. If a write fails after at least one success, the request fails with a 502 `BusinessException` that reports the partial state explicitly: the masters that now store the new TTL, the master that failed together with its error, the masters that were not attempted, and a defined recovery path — the extension is idempotent, so re-running it rewrites every master. A failure on the first write still propagates unchanged (no master was touched, the cluster is still consistent), and the successful all-master path is untouched. ## Brief changelog - `server/src/main/java/org/apache/rocketmq/studio/provider/apache/RocketMQLiteTopicProvider.java`: the TTL write phase now tracks the masters it already updated; on a later write failure it throws a 502 `BusinessException` built by the new `partialTtlUpdate(...)` helper that names the updated, failed and not-yet-attempted masters plus the idempotent-retry recovery path. First-write failures and the all-master success path are unchanged. - `server/src/test/java/org/apache/rocketmq/studio/provider/apache/RocketMQLiteTopicProviderTest.java`: two tests — the regression (three masters, the second write times out) and a guard that a first-write failure still surfaces as the plain write error without touching the next master. ## Verifying this change - red: `<worktree>\server` `mvn -o -B -ntp test -Dtest='RocketMQLiteTopicProviderTest#extendTtlReportsAPartialWriteInsteadOfABareFailureWhenALaterMasterFails+extendTtlKeepsTheBareWriteFailureWhenNoMasterWasUpdatedYet'` → `Tests run: 2, Failures: 1` with `Expecting actual throwable to be an instance of: org.apache.rocketmq.studio.common.exception.BusinessException but was: org.apache.rocketmq.remoting.exception.RemotingTimeoutException: broker-b write timed out` thrown at `RocketMQLiteTopicProvider.java:409` - green: same command after the fix → `Tests run: 2, Failures: 0, Errors: 0` - regressions run: `mvn -o -B -ntp test -Dtest='RocketMQLiteTopicProviderTest,LiteTopicServiceTest,LiteTopicControllerTest,LiteTopicExtendTtlToolHandlerTest,LiteTopicListToolHandlerTest,LiteTopicQuotaToolHandlerTest,LiteTopicSessionToolHandlerTest'` → `Tests run: 59, Failures: 0, Errors: 0` - not run: the full backend suite, CI, and a live multi-master broker cluster. The reproduction uses the existing `MQAdminExt`/Mockito boundary, so it does not exercise real broker timeouts or a real mixed-expiration cluster. ## Checklist - [x] one issue, one PR: Fixes #7085 - [x] regression test added - [x] targeted suites re-run -- 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]
