zjncs opened a new pull request, #4578:
URL: https://github.com/apache/rocketmq-dashboard/pull/4578
### Which Issue(s) Are Addressed
No issue yet; found while auditing the LiteTopic provider added in #4220.
### Brief Description
`extendTTL` examined and updated the masters in a single pass, and the
`liteTopicConfig` helper collapsed **every** read failure into the same `null`
as "topic not configured on this master":
```java
TopicConfig config = liteTopicConfig(admin, master, topicPattern);
if (config == null) {
continue; // skipped for absence AND for RPC failures
}
...
admin.createAndUpdateTopicConfig(master, config);
updated++;
```
When `examineTopicConfig` failed on one master (timeout, restart,
connectivity blip) while succeeding on another, the loop silently skipped the
failing master, answered 200, and logged "1 broker(s)" — leaving the cluster
with mixed `lite.topic.expiration` attributes. LMQ expiry
(`cleanExpiredLiteTopic`) is evaluated by each broker against its own local
topic config, so lite topics on the un-updated master kept expiring under the
old TTL while the console reported the extension as fully successful.
The fix reads every master's config **before** writing any of them. The new
`liteParentTopicConfig` keeps the legitimate skips distinct from failures:
* topic absent on this master — `MQClientAPIImpl.getTopicConfig` throws
`MQBrokerException` with `ResponseCode.TOPIC_NOT_EXIST` — still a skip (matches
the multi-master reality where a parent topic may not be configured everywhere);
* config present but not `TopicMessageType.LITE` — still a skip (the
existing 404 semantics for non-lite topics are unchanged);
* any other failure — propagates, so the request fails **before the first
write** instead of after a partial update. Retrying after such a failure
converges the cluster because the update is idempotent.
### How Did You Test This?
Fail-before / pass-after (Java 21, standalone maven):
```
mvn -B -ntp test -Dtest='RocketMQLiteTopicProviderTest' -Dspotbugs.skip=true
# before fix: Tests run: 16, Failures: 1
# extendTtlFailsInsteadOfPartiallyUpdatingWhenAMasterCannotBeRead FAILED
# (no exception thrown; createAndUpdateTopicConfig WAS called on the
reachable master)
# after fix: Tests run: 16, Failures: 0
```
New regressions:
* `extendTtlFailsInsteadOfPartiallyUpdatingWhenAMasterCannotBeRead` — two
masters, the second one's `examineTopicConfig` throws
`RemotingTimeoutException`; asserts the call fails and **no** master was
written (old code updated broker-a and returned normally).
* `extendTtlStillUpdatesReachableMastersWhenTheTopicIsAbsentOnAPeer` — the
peer throws `MQBrokerException(TOPIC_NOT_EXIST)`; asserts the reachable master
is still updated and the peer is not, pinning the absence/failure distinction
the new classification relies on.
Full lite area after the fix:
```
mvn -B -ntp test
-Dtest='RocketMQLiteTopicProviderTest,LiteTopicServiceTest,LiteTopicControllerTest,LiteTopicSessionTest'
-Dspotbugs.skip=true
# Tests run: 36, Failures: 0, Errors: 0
mvn -B -ntp checkstyle:check # BUILD SUCCESS
```
### Checklist
- [x] Code follows the project's coding style (Conventional Commits,
checkstyle clean)
- [x] Added/updated tests covering the fix
- [x] All tests pass locally
Signed-off-by: zjncs <[email protected]>
--
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]
