ai-yang opened a new pull request, #10759: URL: https://github.com/apache/rocketmq/pull/10759
### Which Issue(s) This PR Fixes Fixes #10756 ### Brief Description `ConsumeQueue.putMessagePositionInfoWrapper()` allocated a `ConsumeQueueExt` unit before the main CQ idempotency check. Replaying a duplicate dispatch therefore skipped the CQ append but still left an unreferenced Ext unit, which a later valid dispatch could seal inside the live Ext range. This change reuses the main CQ physical-end idempotency predicate before allocating an Ext unit. Duplicate replay still follows the existing successful wrapper path, so checkpoint advancement and multi-dispatch behavior are preserved while the orphan allocation is avoided. ### How Did You Test This Change? - Unmodified `develop`: the deterministic duplicate-dispatch regression failed in 5/5 isolated JDK 8 Maven processes. - Fixed targeted regression: 20 isolated Maven/JVM processes, 1/1 each (20/20 total). - Complete `ConsumeQueueTest`: 11/11. - Full `store -am test`: common 241/241, remoting 174/174, and store 314 tests with 4 skips, 0 failures, and 0 errors. - Maven validate and Checkstyle: 0 violations. - SpotBugs: 0 bugs/errors across all four reactor modules. - `git diff --check`: passed. ### Scope and Concurrency The new guard reuses the physical-end idempotency predicate already applied by `putMessagePositionInfo()` on the same dispatch attempt. It introduces no new shared state or locking and leaves supported writes, checkpoint advancement, retries, and multi-dispatch handling unchanged. This PR is scoped to duplicate re-dispatch; cleanup after a genuine Ext-append/CQ-append failure remains a separate failure mode. ### Applicability and user-visible impact `enableConsumeQueueExt` defaults to `false`. The affected path requires CQExt writes and duplicate Broker dispatch/recovery of an already-indexed physical message. This is internal index-build idempotency, not producer retry deduplication or an exactly-once delivery feature. The demonstrated impact is unreferenced extension allocation and extra storage retained in the live Ext range. It is not evidence of lost message bodies or permanent retention under every cleanup policy. Total disk cost and eventual reclamation depend on duplicate volume, mapped-file boundaries and normal retention cleanup; no production byte estimate or occurrence rate is claimed. -- 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]
