RockteMQ-AI commented on issue #10666: URL: https://github.com/apache/rocketmq/issues/10666#issuecomment-5101570232
**Issue Evaluation** Category: `type/bug` | Status: **Confirmed** The reported crash-safety issue in `AutoSwitchHAService` truncation has been verified against the current codebase on the `develop` branch. **Root Cause:** `MappedFileQueue.truncateDirtyFiles()` (line 217) only resets in-memory positions (`wrotePosition`, `committedPosition`, `flushedPosition`) for the target `MappedFile`. The physical bytes after the truncation offset remain unchanged on disk — no zeroing or invalidation is performed. ```java // MappedFileQueue.java:224-228 file.setWrotePosition((int) (offset % this.mappedFileSize)); file.setCommittedPosition((int) (offset % this.mappedFileSize)); file.setFlushedPosition((int) (offset % this.mappedFileSize)); ``` **Why CRC check does not prevent recovery of stale data:** `checkCRCOnRecover` defaults to `true`, but the stale tail bytes are exact replicas of previously valid messages replicated from the master. Their magic code, total size, physical offset, and CRC are all intact. `CommitLog.recoverNormally()` (line 348) scans these bytes via `checkMessageAndReturnSize()` and accepts them as valid messages. **Failure scenario (confirmed):** 1. Slave receives and persists messages up to offset X 2. Master truncates its log to offset T (T < X) due to a divergent epoch 3. Slave reconnects, `AutoSwitchHAClient.doTruncate()` calls `truncateFiles(T)` → only resets in-memory positions 4. Slave crashes before master overwrites bytes [T, X) 5. On restart, `CommitLog.recoverNormally()` scans the file and recovers stale messages in [T, X) 6. Slave now has divergent data that the master does not have → data inconsistency **Impact:** Data inconsistency between master and slave in Controller mode. The slave may serve or replicate messages that the master has already truncated. **Severity:** High — affects data integrity in Controller mode failover scenarios. **Suggested fix direction:** In `truncateDirtyFiles()`, after resetting in-memory positions, physically zero out or invalidate the bytes from the truncation offset to the end of the mapped file (e.g., write a zero-filled buffer or set the magic code of the first stale message to an invalid value). An automated fix proposal will be generated. Reply `/approve` to proceed with PR generation, `/revise` to request changes to the approach, or `/reject` to decline. --- *Automated evaluation 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]
