STATE & RECOVERY · REVISION INSPECTION DESK
Session resumption: recover a consistent revision
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
Disable replay, observe the older restored revision, then enable it. Describe the difference between resuming a snapshot and recovering all committed transitions.
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.
Resume to a revision, not to a guess
A resumed agent session should continue from a state that some committed revision actually had. This store starts at zero, workers A and B stage increments of one and two in each of two rounds, and every commit creates a numbered revision. Under compare-and-swap the store ends at value 6, revision 4. A crash then discards worker drafts and process memory. Resumption loads the newest checkpoint and replays durable events written after it, so the recovered pair of value and revision can be checked against the log.
A consistent revision depends on the write policy
Choose Last write wins. Both workers read the same revision and the later write replaces the earlier one, so the store ends at four, not six, while still showing four commits and zero conflicts. Recovery faithfully resumes that wrong value: replay can only restore what was committed. Switch to Atomic increment at store and the value reaches six with no conflicts. Return to compare-and-swap and clear Re-read and retry stale intent: two stale writes are rejected and the resumed session continues from value two.
What survives the crash
With the defaults the checkpoint holds value 4 at revision 3 and the log holds four events. Resumption loads revision 3 and replays revision 4, reaching value 6. Clear Persist event history and the session resumes at revision 3 with value 4, a consistent but older revision: the most recent committed turn is gone. Clear only Replay events after checkpoint and the result is the same, even though the log survived. Raising the interval to five with replay off resumes at revision 0.
Remaining controls
Worker A increment per round and Worker B increment per round change the intended total, which is twice their sum. Checkpoint every N commits sets how often a snapshot is persisted; one means every commit. Inject process crash turns recovery on or off, and without it the session simply finishes at revision 4. Append compensation after recovery records a reverse event that subtracts the last delta, producing revision 5 with value 4 when history is durable; without durable history the compensation is refused rather than guessed.
Playback and scope
Play, Pause, Next transition, Restart, Speed and Time inspect the snapshots; Export replay JSON saves the whole run. A real session service also needs session identity, ownership checks, lease or fencing tokens so two resumed processes do not both write, and idempotent handling of tool calls that were in flight. None of those are modeled here, and the store is a single counter rather than a conversation transcript.