fuyou001 commented on PR #10657: URL: https://github.com/apache/rocketmq/pull/10657#issuecomment-5098735605
**[P1] Handle end timestamps already overwritten by the legacy recovery path** The offset change is correct for a file that has not previously been reopened by the affected implementation. However, the old constructor loads `INDEX_BEGIN_TIME_STAMP` into `endTimestamp` and then immediately calls `flushNewMetadata()`, which writes that incorrect value back to `INDEX_END_TIME_STAMP`. Therefore, an existing file recovered by the old code can already have `endTimestamp == beginTimestamp` persisted, and upgrading to this patch will still read the corrupted value. This is observable in `IndexStoreService.queryAsync()`: when a query begins after the corrupted value but before the file’s actual end time, `getEndTimestamp() < beginTime` causes the scan to `break`, skipping valid index entries. The added test covers only the first clean reopen, so it does not exercise this upgrade path. Could recovery validate or rebuild a suspicious end timestamp from the stored index items, or conservatively avoid using it for pruning until it is rebuilt? Please also add a regression test that simulates the legacy recovery/write-back before reopening the file with the fixed code. -- 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]
