Memgraph makes damaged mid-chain WAL files fatal on recovery

Memgraph shipped version 3.13.0 with a fix for a data loss bug that never announced itself. Before this release, a crash that left a write-ahead log (WAL) file damaged partway through didn't stop recovery. Recovery replayed the readable prefix of that file, then applied every WAL file after it in full, producing a dataset missing whatever came after the damage. No error, no warning.

That matters most for anyone running replicas, since it's the case where the gap doesn't just cost data, it costs trust in the data. A replica in that state reports the timestamp of the last WAL it processed, and main reads that timestamp and considers the replica caught up. The divergence never healed on its own.

Memgraph's 3.13.0 release changes what happens when a WAL file that's already been finalized on disk turns up damaged: recovery now stops instead of continuing past it. Hitting that case means using --storage-allow-recovery-failure combined with RECOVER SNAPSHOT, or restoring from a backup. A WAL still open at the moment of the crash is handled differently. It's truncated to its last whole transaction, and recovery proceeds from there.

The release notes don't say how long the silent version of this bug shipped, or how anyone would have detected an already-diverged replica under the old behavior. That's the open question for anyone who's had Memgraph replication running for a while: the new version stops the bug from happening again, but it doesn't tell you whether it already happened to you.