[zahariash]

This work was produced with the help of language models.

Fixes #1357.

Opening a database with enableChecksums set the other way from its WAL's header deleted the WAL, and every commit in it, when throwOnWalReplayFailure was false, the engine default. dryReplay checked the flag inside the try whose catch (...) turns read errors into a torn tail, so the mismatch was taken for a WAL without a complete commit. The flag is now read with the plain reader before that try, the way attached-graph recovery already reads it (tryReadWALChecksumFlag). The checksum writer puts each object's checksum after its bytes, so the header sits at the same offset in both modes. A mismatch throws the existing enableChecksums error in both modes and leaves the WAL untouched. A header too short to hold the flag holds no commit, so it still takes the lenient path. The main WAL and the frozen checkpoint WAL both go through dryReplay; graph WALs already take the flag from their own header.

The enableChecksums comment on SystemConfig and docs/checkpoint_recovery.md now say that the setting must match the WAL.

Behavior change. With throwOnWalReplayFailure false, the C++ and C API default, an open with the other enableChecksums setting used to succeed and silently drop every commit in the WAL. It now throws the enableChecksums error, for read-write and read-only opens alike, so an embedder on the lenient default sees a new error where it got an open but empty database. Reopening with the matching setting recovers the commits.

Tests. WalTest.WALChecksumConfigMismatchNoThrow expected the open to succeed with no tables left. It now expects the enableChecksums error from a read-only and a read-write open, the WAL's bytes unchanged, and both tables back after reopening with the right setting. FrozenWALRecoveryTest.FrozenWALWithOtherChecksumSettingIsKept checks the same, without the read-only open, for a frozen checkpoint WAL of 100 inserts, which main deleted. It writes the WAL with the setting flipped, so the two tests cover both directions. Both fail on main. WalTest.TornWALHeaderNoThrow cuts the WAL to 10 bytes, shorter than the 16-byte database ID, and opens with the other setting: the open succeeds with no tables, as on main. Full ctest (Release, runtime checks on): 3166 passed.

[adsharma]

Low (non-blocking, both call sites verified correct): two bare bools (walEnableChecksums, enableChecksums) read naturally in either order. Consider an enum or keeping the header-typed parameter so a swap is a compile error.

[zahariash]

Done in e1210ec: tryReadWALHeader returns the header and checkWALHeader(const WALHeader&, bool) takes it, so the two flags can no longer be swapped silently.

[adsharma]

[ release notes are generated from PR descriptions, so no separate action needed ]

One callout from review (inline nit posted separately):

Intended behavior break — release note needed: opens that previously succeeded with throwOnWalReplayFailure=false (the C++/C engine default) now throw, including read-only opens. That is exactly the fix (previously 'success' meant silent loss of every WAL commit), and docs/comments are updated in-PR — but downstream/embedders on the lenient default will see a new throw where they got an empty-but-open DB. Release notes here are auto-generated from PR titles so no separate file to edit; just making sure the behavior break is explicit in the PR body before merging. (Re-posting: my earlier comment on this did not persist.)

[zahariash]

Thanks — the body now has a Behavior change paragraph: read-write and read-only opens on the lenient default now throw instead of opening without the WAL's commits.