[BUG] Snapshot recovery is dead code — SAVE data is never loaded back

[Hogwarts-coder10]

Problem:

KedisStore.init only calls recover_from_aof(). load() (which reads dump.json) is never called anywhere in the codebase.

# store.py:42
self.recover_from_aof()   # only this runs on startup
# load() is defined at store.py:321 but has zero call sites elsewhere

Running SAVE returns OK, but on restart that data is never read back — only AOF replay restores state. The snapshot file is currently write-only.

Fix:

Either wire load() into startup with proper precedence (load snapshot baseline, then replay only AOF entries written after the snapshot), or
Pull SAVE/snapshotting out of the README/feature list until it's actually connected to recovery.

[Hogwarts-coder10]

Design Decision: Hybrid (Snapshot + AOF) Recovery

Problem

KedisStore.init only calls recover_from_aof(). load() (reads dump.json) has zero call sites anywhere in the codebase. SAVE returns OK but the snapshot is never read back — only AOF replay restores state on restart. The snapshot is currently write-only.

Chosen approach: Hybrid recovery

Going with snapshot + AOF instead of either alone, so we get fast recovery (snapshot baseline) without losing durability for writes since the last SAVE (AOF tail). This requires solving one core problem: recovery needs to know which AOF entries are already covered by the snapshot, or replay will double-apply them (e.g. an LPUSH already baked into the snapshot gets pushed a second time — silent data corruption on every restart).

Mechanism: AOF byte-offset stored inside the snapshot

save() flushes/fsyncs the AOF first, records self.aof_file.tell() as aof_offset, then writes {data, expires, aof_offset} to a temp file and atomically os.replace()s it into dump.json. Same temp+rename pattern compact_aof() already uses for the AOF — fixes #10 (non-atomic SAVE) as a side effect, no separate fix needed.
recover_from_aof(start_offset=0) seeks to that offset before replaying, so only AOF entries written after the snapshot get re-applied.
Startup sequence: load snapshot → read aof_offset → replay AOF starting from that offset (instead of byte 0).

No second file operation between "write the snapshot" and "record what's covered" — the offset lives inside the same atomically-written JSON, so there's no window where a crash leaves recovery in an ambiguous state.
Failure modes considered

Crash mid-snapshot-write → temp file never renamed → old/no dump.json left untouched → falls back to aof_offset = 0 (full AOF replay, identical to current behavior). Never worse than today.
Corrupt/unreadable snapshot on load → wrap json.load() in try/except → fall back to aof_offset = 0.
AOF byte offset past end of file → guard: if aof_offset > os.path.getsize(aof_filename), clamp to 0 and replay the full file.

⚠️ Interaction with COMPACT (caught during review — important)

compact_aof() only rewrites the AOF file — it has no knowledge of dump.json/aof_offset. If COMPACT runs after a SAVE, the AOF gets entirely rewritten with new content and a new length. The snapshot's stored aof_offset now points into a different file with unrelated content at that byte position — seeking there on recovery can land mid-command and produce garbage, or silently be wrong. The size-only guard above does not catch this case (it only catches offset-past-EOF, not offset-into-wrong-content).

Required fix:

compact_aof() must call save() again immediately after rewriting the AOF, so the snapshot's aof_offset is refreshed to match the newly compacted file. The pairing has to go this direction — compacting re-triggers a snapshot, not the other way around — since SAVE has no reason to know COMPACT ever ran.
Until that pairing is implemented: SAVE and COMPACT are not safe to use together. Running COMPACT after a SAVE invalidates that snapshot's offset.

Out of scope for this issue

AOF still grows unbounded between compactions — this fix only skips already-snapshotted entries on read, it doesn't reclaim disk space. Tracked separately once the SAVE/COMPACT pairing above is solid.