STATE & RECOVERY · REVISION INSPECTION DESK
Checkpointing: recover the gap after a snapshot
Follow concurrent drafts into committed revisions, inspect the checkpoint and reconstruct state after a simulated crash.
Scroll the diagram horizontally to inspect every label. The panels below give the same state as text.
Your experiment
Set checkpoint interval to three commits. Inspect the fourth committed transition and show how event replay fills the gap after a crash.
Each transition takes three playback seconds. Pause, step or scrub to inspect the state before and after an operation. Capture a baseline before changing policy.
Current snapshot
Recent transitions
Offline application-state exercise, not an ADK storage implementation or database benchmark. Two workers add configured integers in two fixed interleavings. Checkpoints and optional event history are assumed durable and atomically written; all actual data remains in this browser simulation. Process state is volatile. Compare-and-swap rejects stale revisions; retry re-reads and reapplies intent. Replay applies recorded state values without repeating tool side effects. Compensation reverses the last recorded state delta only when durable history is present and fully replayed; it cannot undo external effects. No distributed consensus, transactional crash window, migration, personal data or durability guarantee is modeled. ADK state concepts · Event-sourcing reference.
What the checkpoint actually covers
Two workers each intend two increments: worker A adds one per round and worker B adds two, so the intended total is six. Under the default compare-and-swap policy a commit succeeds only if the worker read the current revision. The store reaches value 6 at revision 4. Checkpoint every N commits is three, so the durable checkpoint holds value 4 at revision 3. The crash then discards in-memory state; the gap between revision 3 and revision 4 is exactly the work a checkpoint alone cannot restore.
Close the gap with the event history
With Persist event history and Replay events after checkpoint enabled, recovery loads revision 3 and replays the recorded transition to revision 4, ending at value 6. Replay copies recorded results; it does not rerun workers or external tools. Clear Replay events after checkpoint: recovery stops at value 4, revision 3, and two units of committed work are lost. Clear Persist event history instead and the same loss occurs because the log itself did not survive. Set the checkpoint interval to one and replay becomes unnecessary: the checkpoint is already at revision 4.
Choose the interval deliberately
Set Checkpoint every N commits to five with replay enabled. No checkpoint is ever written in four commits, so recovery starts from revision 0 and replays all four events, still reaching six. Now clear replay: recovery returns zero. Setting the interval to four with replay disabled restores six because the only checkpoint happens to land on the last commit. A frequent checkpoint shortens replay; a durable log is what makes a sparse checkpoint safe.
Concurrency before the crash
Re-read and retry stale intent controls what happens after a compare-and-swap conflict. Each round produces one conflict; with retry the stale worker re-reads and reapplies its increment. Without retry only two of four increments commit and the value before the crash is two. Write policy last write wins never conflicts but overwrites, ending at four. Atomic increment at store applies each delta to the current value and reaches six without conflicts. Worker increments change the expected total. Append compensation after recovery subtracts the last delta and is refused without a caught-up durable history.
Inspect and export
Play, Pause, Next transition, Restart, Speed and Time step through the recorded snapshots, and Export replay JSON downloads them for inspection. The model has one store, one crash point after all commits, and instant durable writes. It does not model fsync ordering, torn writes, partially written checkpoints, log truncation, snapshot isolation or the side effects of tools that were running when the process stopped, which in real agents need idempotency keys or reconciliation.