The Checkpoint That Didn't Survive Reboot
CHECKPOINT_ROLLBACK_AFTER_REBOOT — visible is not durable
Collector Platform: The service logged checkpoint saved: offset=42, and an immediate read returned 42. After a host failure it recovered offset 41 and replayed already-processed events.
The trap: Writing a temporary file and renaming it provides atomic visibility, but buffered data and the renamed directory entry may not yet be crash-durable. A successful read-after-write does not prove power-loss persistence.
Your task
Fix `save_checkpoint()` in `src/lib.rs`. Write and flush the temporary checkpoint, synchronize the file, rename it on the same filesystem, synchronize the parent directory, and propagate every error before acknowledging success. CI uses a deterministic Linux-like crash model plus a real temporary-directory test.
Book: Rename is atomic, so the checkpoint is safe. Prod: Atomic visibility and durability are separate guarantees.
Skills you'll prove
Interview Tip
Atomic replacement and crash durability are different guarantees. I write and flush a temporary file, sync the file, rename it within the destination filesystem, and sync the parent directory before acknowledging the checkpoint. Every error is propagated. Deterministic crash modeling can validate the required ordering, while ordinary process-kill or read-after-write tests do not prove physical power-loss durability.