The final lesson puts the whole engine on trial. You write a batch, simulate a crash with no clean close, leave a torn SSTable behind, then reopen the directory and prove that every committed key survived and the torn file was ignored.
Simulate a crash after committed writes and a torn flush, reopen, and prove no committed data is lost.
This is the promise the whole project was built to keep. The test does what a real crash does: commits writes through the durable path, leaves a torn SSTable behind from an interrupted flush, and then walks away from the store with no clean close - no flush, no cleanup, nothing. Reopening the directory is the moment of truth, and it leans on everything you built: WAL append-and-fsync makes the batch durable, atomic rename plus footer validation makes the torn table skippable, and replay rebuilds the memtable from the log.
The result is a store where every acknowledged write survives and a half-finished flush costs nothing committed - the defining property of a crash-safe storage engine. From a sorted in-memory map you have built a real LSM engine: a fsynced write-ahead log, immutable indexed SSTables, merge-iterator reads with newest-wins and tombstones, leveled compaction, and bloom filters, all behind a small durable API. That is the honest core every production key-value store - from LevelDB to RocksDB - is built around.
// 1. Open(dir); WriteBatch(3 keys); (optionally trigger a flush)// 2. corrupt: truncate the newest .sst mid-file to fake a torn flush// 3. DROP the handle - no Close, no cleanup (this is the crash)// 4. Open(dir) again -> replay recovers the batch, torn .sst skipped// 5. assert all committed keys present, torn table gone, Scan sorted