Repository navigation
fix(wal): never append after a torn WAL entry (#513, v2.x backport) - #516
Merged
Merged
Conversation
Backport of #514 from v3. WAL replay stops at the first partial or damaged entry, but the writer appended at the end of the file. After a crash during an append, the next session's commits went in after the partial entry, so a second crash before any checkpoint lost them although each was fsynced and reported committed. A failed append in a running process did the same to the next commit through that handle. - WalWriter::open_or_create cuts an existing WAL back to the end of its last valid entry and syncs it before appending (scan_entries, shared with WalReader::read_entries). - After a failed write or sync, the writer refuses every later append with the new WAL-007 (same code as v3). A checkpoint or a reopen starts a clean writer. A rejected oversize fact (WAL-003) does not poison it. Same tests as on v3 (the oversize fact uses v2's MAX_FACT_BYTES). Refs #513 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012wXxZguv7PgKQjMMH4yJ5h
Codecov Report❌ Patch coverage is
📢 Thoughts on this report? Let us know! |
This was referenced Oct 10, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Refs #513 (data-integrity: stays open until the fix is in a published release). v2.x backport of #514 (merged on
v3), for a v2.0.5 patch under the support policy.Problem
WAL replay stops at the first partial or damaged entry, but
WalWriterappended at the end of the file. After a crash during an append, the next session's commits went in after the partial entry, so a second crash before any checkpoint lost them, although each was fsynced and reported committed. A failed append (short write, ENOSPC, EIO) did the same to the next commit through that handle. Affects v0.5.0 through v2.0.4.Fix (same as v3)
WalWriter::open_or_createcuts an existing WAL back to the end of its last valid entry and syncs it before appending.WAL-007(same number as on v3). A checkpoint or reopen gives a clean writer. A rejected oversize fact (WAL-003) does not poison it.Cherry-picked from 25582a6. The conflicts were the header-validation line, the docs and the test counts. The oversize-fact test uses v2's
MAX_FACT_BYTES.Not backported: the #390 "never retry a failed checkpoint" rule (
STG-046, #515). v2's checkpoint is not copy-on-write; its crash behavior is known issue #374.Tests
The WAL unit tests, the
MinigrafWAL-007test, and thetests/wal_test.rstorn-tail second-crash test, all as on v3. 1,231 tests (1,223 passing, 8 ignored); clippy and fmt clean.Bindings: this adds an
ErrorCodevariant on v2.x, which the UniFFI bindings (Python/Java/Android/Swift) need to know about at release time.🤖 Generated with Claude Code
https://claude.ai/code/session_012wXxZguv7PgKQjMMH4yJ5h