Repository navigation
[ISSUE #11452] fix(common): name the file in the checkpoint crc mismatch message - #11453
Conversation
CheckpointFile.read builds the IOException for a crc32 mismatch with a "file=%s" label but passes expectedCrc32 into it, so an operator who opens a corrupted checkpoint reads e.g. "file=823222925" - a checksum where the path that failed to load is expected - and the expected value itself is never named. Pass the path that was read and label the expected checksum, and pin it with the case that corrupts both the checkpoint and the .bak fallback read() falls back to.
RockteMQ-AI
left a comment
There was a problem hiding this comment.
Review by github-manager-bot
Summary
This PR fixes a bug in CheckpointFile.read() where the CRC32 mismatch error message was printing the expected CRC value in the file=%s placeholder instead of the actual file path. The fix correctly passes filePath as the first format argument and adds a labeled expected=%s field for the expected CRC value. A new unit test validates the corrected error message.
Assessment: ✅ Looks Good
Correctness:
- The original bug is clear:
String.format("file=%s, truth=%s", expectedCrc32, truthCrc32)was passing alongwhere aString(file path) was expected in the format string. - The fix
String.format("file=%s, expected=%s, truth=%s", filePath, expectedCrc32, truthCrc32)correctly resolves the argument order and adds proper labeling. - The
filePathparameter is available in scope (read(String filePath)), so no additional plumbing is needed.
Test Coverage:
testCrcMismatchReportsTheFileAndTheExpectedCrcis well-structured: it corrupts both the primary and.bakcheckpoint files, triggers the read, and asserts the error message contains the file path, expected CRC, and truth label.- The test correctly uses
System.lineSeparator()for cross-platform compatibility.
Minor Observations:
- The error message format change is backward-incompatible for any tooling that parses this specific error string. However, since this is a diagnostic message for operators (not a machine-readable protocol), this is acceptable.
- Consider whether
filePathshould be logged as an absolute path for easier debugging in production environments. Currently it depends on how the caller constructs the path.
Verdict
Clean, focused fix with proper test coverage. No blocking issues.
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## develop #11453 +/- ##
=============================================
- Coverage 49.76% 49.72% -0.05%
+ Complexity 14377 14369 -8
=============================================
Files 1390 1390
Lines 103262 103262
Branches 13504 13504
=============================================
- Hits 51392 51350 -42
- Misses 45681 45713 +32
- Partials 6189 6199 +10 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Which Issue(s) This PR Fixes
Fixes #11452
Problem
CheckpointFile.readreports a crc32 mismatch with afile=%slabel but passesexpectedCrc32into it, so a corrupted checkpoint prints a checksum where the path belongs and never labels the expected value:The path being read is in scope (
read(String filePath)) when the message is built.Change
Verification
CheckpointFileTest(the module that already owns the checkpoint test) gainstestCrcMismatchReportsTheFileAndTheExpectedCrc, which corrupts the stored crc32 on both the checkpoint and its.bakfallback and asserts the message names the path and the expected checksum. Before the change:After the change, with JDK 8 (
mvn -B -ntp -pl remoting -am test -Dtest='CheckpointFileTest' -DfailIfNoTests=false -Djacoco.skip=true):The unit test is the verification for this one. The change was prepared with AI assistance and reviewed, tested and verified by me.