STATE & RECOVERY · REVISION INSPECTION DESK
Session storage: inspect what survives a crash
Follow concurrent drafts into committed revisions, inspect the checkpoint and reconstruct state after a simulated crash.
Your experiment
Disable durable history and inspect the recovered checkpoint. Compare it with the last state before the crash; a visible session value is not necessarily a durable value.
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.
Separate live state from durable recovery evidence
Two workers each intend one increment in each of two rounds. They first read the same revision, then attempt writes in a fixed A-before-B order. The desk displays local drafts, the currently committed value, a checkpoint and an event history. These are different pieces of evidence: a value visible before the injected process crash is not necessarily present in the durable checkpoint. The final preview summarizes the complete chosen scenario, while the moving state and JSON snapshot show only the inspected transition. Compare them deliberately instead of treating a preview as work already executed.
Choose write conflict behavior
Write policy selects compare-and-swap, last-write-wins or atomic increment. Compare-and-swap rejects a stale base revision. Re-read and retry stale intent makes that worker read the new revision and reapply its original increment; the checkbox is inactive for other policies. Last-write-wins accepts the worker’s stale staged value, allowing an update to be overwritten. Atomic increment adds directly to the current store value instead of using the draft. Worker A increment per round and Worker B increment per round change the intended arithmetic. With defaults one and two, the intended total is six; last-write-wins finishes the two rounds at four, while atomic increment and compare-and-swap with retry reach six.
Make a checkpoint gap visible
Checkpoint every N commits writes a checkpoint after each matching successful commit, not after every worker read or rejected write. Persist event history determines whether the log survives the injected crash. Replay events after checkpoint reconstructs later recorded revisions only when that history is durable. Inject process crash exercises this recovery path; disabling it leaves the live state in place and makes replay irrelevant. With defaults, the third commit checkpoints value four and the fourth reaches six. Disable durable history or disable replay: recovery restores four. Set the checkpoint interval to four and repeat without replay: the checkpoint itself now contains six.
Compensate without erasing the past
Append compensation after recovery requests a new revision subtracting the last recorded state delta. It is allowed only with durable history that reaches the current revision. Under the default recovered history, the last increment is two, so compensation takes six back to four while adding a fifth event. It does not remove the earlier event or undo an email, payment or other external action. If the history is not durable or recovery is behind its latest event, compensation is refused. Inspect both the appended event kind and the final revision rather than judging success from the value alone.
Use inspection and export controls
Play and Pause control inspection; Next transition advances one recorded state; Restart rewinds without changing inputs; Speed changes viewing pace; Time scrubs. Each transition takes three inspection seconds, so total duration depends on checkpoints and recovery events. Editing a policy starts the rebuilt scenario unless reduced motion is requested. Export replay JSON downloads the complete synthetic model and trace, not a real session backup. All actual state exists only in browser memory. Atomic checkpoint writes and durable history are assumptions; the fixture does not model a crash during persistence, transactional storage, distributed consensus, schema migration, or ADK infrastructure.