RockteMQ-AI commented on issue #10666: URL: https://github.com/apache/rocketmq/issues/10666#issuecomment-5101639693
**Fix Spec Summary** A repair plan has been generated for this issue. **Fix approach:** Physically invalidate the stale CommitLog tail in `MappedFileQueue.truncateDirtyFiles()` after resetting in-memory positions. **Key changes:** 1. Add `MappedFile.eraseAndForce(startPosition, endPosition)` — zero-fills the dirty region via positional `FileChannel.write()` and calls `force(false)` for durability 2. Modify `MappedFileQueue.truncateDirtyFiles()` to capture the old wrote position before reset, then call `eraseAndForce()` on the boundary file **Why zeros (not `BLANK_MAGIC_CODE`):** Zeros yield `totalSize == 0` + `magicCode == 0` in `checkMessageAndReturnSize()`, hitting the "illegal magic code" branch → recovery stops exactly at the truncation offset. `BLANK_MAGIC_CODE` means "skip to next file" which is wrong mid-file. **Scope:** Only `MappedFileQueue.truncateDirtyFiles()` and the `MappedFile` interface/`DefaultMappedFile` implementation need changes. No changes to `AutoSwitchHAClient`, `DefaultMessageStore`, or `CommitLog` truncation paths. **Testing:** Crash-recovery simulation test (truncate → shutdown without flush → restart → verify stale messages are not recovered), plus unit tests for `eraseAndForce` and boundary cases. Reply `/approve` to proceed with PR generation, `/revise <feedback>` to request changes, or `/reject` to decline. --- *Automated fix proposal by RockteMQ-AI* -- 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]
