STATE & RECOVERY · REVISION INSPECTION DESK
State replay: inspect deterministic reconstruction
Follow concurrent drafts into committed revisions, inspect the checkpoint and reconstruct state after a simulated crash.
Your experiment
Capture the final state, restart and repeat. Compare checkpoint-only recovery with replay from the same durable event sequence.
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.
Reconstruct state without executing the worker again
Two workers each intend an increment in each of two rounds. With increments one and two, compare-and-swap and conflict retry, four commits produce values one, three, four and six. Checkpoint every three commits preserves value four at revision three. After the process crash, recovery loads that snapshot and applies revision four, restoring six. The browser computes these transitions locally. Replay copies recorded state transitions; it never reruns a worker, calls an LLM or repeats an external tool effect. This is a deterministic state-change log, not a complete event-sourced business application.
Separate a missing update from a missing event
Write policy selects revision checking, last write wins or an atomic increment at the store. Both workers read before either commits. Last write wins overwrites a stale draft twice and reaches four, even with complete recovery. Compare-and-swap rejects two stale writes; Re-read and retry stale intent preserves both increments and reaches six. Disable that retry and only worker A commits, yielding two. The retry checkbox is disabled for the other policies. Worker A increment per round and Worker B increment per round each range from one to five. Atomic increments with values three and five produce sixteen; they change the store value directly and do not depend on a draft revision.
Make the checkpoint gap visible
Checkpoint every N commits ranges from one to five. A checkpoint interval of four captures all four default commits, so recovery does not need a later event. An interval of five leaves the initial zero snapshot; every committed event is then needed. Persist event history determines whether history survives the simulated crash. Replay events after checkpoint determines whether surviving history is consumed. Turn either off with interval three and the recovered value is four at revision three. Turn Inject process crash off and the volatile value stays six. All durability is an explicit model assumption: browser memory is the actual storage.
Inspect malformed delivery rather than silently accepting it
Replay delivery changes only the delivered copy of the post-checkpoint events; the original committed log remains intact. Use interval five to expose four pending revisions. Missing first event sends revision two while recovery expects one: it stops at zero and reports BLOCKED. Reverse delivery sends revision four first and also blocks. Repeat first event delivers revision one twice; the identical duplicate is skipped, and four unique revisions still restore six. The validator requires contiguous revision numbers and checks that each recorded value equals the previous value plus its delta. It also requires the final revision to reach the known pre-crash watermark. That watermark is trusted fixture information; a real recovery service would need an independently established completeness boundary. With a checkpoint already at the latest revision there are no pending events to corrupt.
Distinguish compensation from erasure
Append compensation after recovery reverses the last committed delta by appending a new revision. Default complete recovery followed by compensation produces value four at revision five, while all original events remain visible. The original intended total still reads six because it describes the two rounds before compensation. Compensation is refused if durable history is unavailable, recovery is blocked or the recovered revision is behind the log. This operation cannot recall an email, refund a payment or reverse another external side effect. Export replay JSON downloads the configuration, steps, delivered event copy and final snapshot, including any recovery error.
Use each inspection control deliberately
Play advances one transition per three inspection seconds; Pause freezes it. Next transition pauses and moves to the next boundary. Restart rewinds while retaining parameters and speed. Time scrubs and pauses. Speed offers quarter, half, normal and double pace, settling elapsed time at the old rate before switching. Parameter changes reset without autoplay, and hiding the tab pauses playback. The duration depends on the number of operations, not measured server latency. Scroll the diagram horizontally on a phone; Current snapshot and Recent transitions provide the same information as text. Capture baseline saves the visible caption, Replace baseline updates it and Clear baseline removes it. Notebook observations persist locally and Export notes downloads them. Expand experiment and Exit full screen control the view. This fixture excludes log corruption on disk, concurrent recovery, schema migration, distributed consensus and transactional crash windows.