Bounded records and recovery policy
What this concept is
A storage record needs an unambiguous boundary, a validity rule and a recovery policy. This lab stores opcode, key length, value length, payload and CRC32. Length bounds are checked as soon as the four-byte header is available, before accepting the body.
Why it matters here
A parser that silently skips damaged bytes can invent a history. A parser that rejects every incomplete final record cannot implement the declared prefix-recovery policy. The reader must distinguish recognized complete corruption from an unfinished final record.
Concrete example
Put key a with value old, then delete a, then put b with empty bytes. A cut inside the delete record leaves a=old visible. A cut exactly after the delete removes a. A complete empty-value put preserves b with a zero-length value. Record length is 8 plus key length plus value length, so even an empty value has a nonempty record.
Common confusion / misconception
A valid checksum is not proof of commitment or authenticity. CRC32 can collide and is not a defense against intentional modification. A corrupted length can describe a plausible incomplete tail; the format has no independent evidence to distinguish that from a torn append. State this ambiguity instead of claiming universal corruption detection.
How to use it
Scan in order. Reject a complete invalid header or checksum mismatch even at EOF. Stop at an incomplete header or incomplete body/checksum following a valid header. Return the last valid byte boundary and unused suffix. Never append after that suffix: either quarantine the log or explicitly repair to the returned boundary before new writes. Readable state and safe continuation are separate decisions.
Check yourself
Why can skipping one bad delete resurrect data? Why must a header declaring 257 value bytes fail even if no payload follows?
Mini drill or application
For a two-record log, list every prefix length and the recovered state. Then corrupt one payload byte and one length byte separately. Explain why the observed failure classifications can differ.
Read this only if stuck
Use Database Internals on recovery and LevelDB log format for a contrasting block/fragments design. Our custom format is not LevelDB-compatible and uses a different checksum convention.