fix(wal): use io.ReadFull instead of f.Read for WAL header reads

[xe-nvdk]

Fixes #341. The WAL reader used f.Read to read fixed-size headers. f.Read may return fewer bytes than the buffer size without error, causing partial reads that cascade into misaligned subsequent reads. Both header reads now use io.ReadFull.

• WAL file header (7 bytes): f.Read → io.ReadFull
• WAL entry header (16 bytes): f.Read → io.ReadFull, io.ErrUnexpectedEOF mapped to io.EOF
• Payload read: = → := (n was previously declared by the removed header f.Read)

All 40 WAL tests pass. gofmt/go vet clean. No configuration-interaction risk.

[gemini-code-assist]

Code Review

This pull request updates the WAL reader to use io.ReadFull instead of f.Read for fixed-size file and entry header reads to prevent partial reads. However, the review feedback highlights two critical issues: first, swallowing all read errors during the file header read is dangerous because transient I/O errors could be mistaken for an empty file, potentially leading to data loss; second, mapping io.ErrUnexpectedEOF to io.EOF when reading entry headers silently ignores truncated or corrupted entries at the end of the WAL file, bypassing corruption logging and metrics.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[xe-nvdk]

@gemini-code-assist please review

[gemini-code-assist]

Code Review

This pull request improves the robustness of the WAL reader by replacing f.Read with io.ReadFull for fixed-size file and entry header reads, preventing potential corruption from partial reads. The review feedback suggests optimizing performance and reducing heap allocations by using stack-allocated fixed-size arrays instead of slices for the header buffers.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[xe-nvdk]

@gemini-code-assist please review

[gemini-code-assist]

Code Review

This pull request updates the WAL reader to use io.ReadFull with fixed-size arrays for reading file and entry headers, preventing partial reads from corrupting subsequent entries. The review feedback highlights a critical issue in readEntry where io.ErrUnexpectedEOF is not handled. If a crash results in a partially written entry header, the reader will fail with a hard error instead of gracefully stopping at the end of the valid entries. A code suggestion is provided to map io.ErrUnexpectedEOF to io.EOF to ensure robust recovery.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[xe-nvdk]

@gemini-code-assist please review

[gemini-code-assist]

Code Review

This pull request updates the WAL reader to use io.ReadFull for fixed-size file and entry header reads to prevent partial reads from causing misaligned subsequent reads. It also updates the release notes to document this change. Feedback on the changes suggests that mapping io.ErrUnexpectedEOF to io.EOF when reading entry headers will cause truncated entry headers (e.g., from a crash mid-write) to be silently ignored instead of being flagged as corrupted. It is recommended to let io.ErrUnexpectedEOF propagate as an error so the caller can properly log and track the corruption.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[xe-nvdk]

mapping io.ErrUnexpectedEOF to io.EOF when reading entry headers will cause truncated entry headers (e.g., from a crash mid-write) to be silently ignored instead of being flagged as corrupted.

Respectfully, this recommendation would reintroduce the cascading misalignment bug #341 describes. Here is the trace:

If io.ErrUnexpectedEOF propagates as an error instead of being mapped to io.EOF:

readEntry → fmt.Errorf("...: %w", io.ErrUnexpectedEOF)
caller:   err == io.EOF?  → NO (wrapped in fmt.Errorf)
caller:   err != nil → CorruptedEntries++ → continue
           ↑ file offset is 1–15 bytes into a partial header
           ↑ next readEntry parses garbage as payloadLen/timestamp/checksum
           ↑ CASCADING MISALIGNMENT — the exact bug #341 exists to fix

The file offset after a partial io.ReadFull on the entry header is unrecoverable. There is no way to skip forward — we do not know the payload length because the header is incomplete. The only correct action is to stop reading.

The io.EOF mapping matches the original code behavior: the original f.Read code checked err == io.EOF before the n < WALEntryHeaderSize check. A f.Read returning (10, io.EOF) would match err == io.EOF first and return io.EOF — treating a truncated header at EOF as clean end-of-file, not as a corrupted entry.

Corruption tracking (CorruptedEntries++) is meant for recoverable corruption within a valid entry (checksum mismatches), not for unrecoverable partial headers at crash points.