STATE & RECOVERY · REVISION INSPECTION DESK
State management: concurrent intent and revisions
Follow concurrent drafts into committed revisions, inspect the checkpoint and reconstruct state after a simulated crash.
Scroll the diagram horizontally to inspect every column. The exact state and trace below provide text alternatives.
Your experiment
Use last-write-wins, then compare-and-swap with conflict retry. Explain the missing increments by inspecting the two workers’ stale drafts.
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.
Follow four intended increments
Two workers read the same counter in each of two rounds. Worker A intends to add one and worker B intends to add two by default, making the intended total six. Each draft records the value and revision it read. The simulation then commits A before B in each round, exposing a repeatable stale-read conflict. This schedule is deliberate: it is not random load testing or a benchmark of a database, agent framework or session service. The diagram and snapshot show the actual computed value, revision, draft and event records after each operation.
Compare the three write policies
Write policy selects last-write-wins, compare-and-swap or atomic increment. Last-write-wins accepts stale drafts and finishes at four instead of six before recovery. Compare-and-swap rejects a draft based on an outdated revision. With Re-read and retry stale intent enabled, B rereads and reapplies its original increment, reaching six with two conflicts; without retries only the two A increments commit, reaching two before recovery. Atomic increment applies each delta to the current store and reaches six without conflicts. Worker delta controls change those arithmetic intentions; they do not change the fixed order of reads and writes.
Locate the recovery gap
Restore the defaults, keep Inject process crash enabled, and set Checkpoint every N commits to three. The third successful commit persists value four at revision three. A durable event log contains all four committed transitions. With Replay events after checkpoint enabled, recovery loads that checkpoint and applies the remaining recorded transition, restoring six at revision four. Disable replay to stop at four. Disable Persist event history and the crash erases history, so replay cannot fill the gap. Set checkpoint frequency to four and the final value is already checkpointed. With a frequency larger than the number of commits, recovery can fall back to the initial zero checkpoint.
Keep compensation distinct from erasure
Append compensation after recovery appends an inverse delta to caught-up durable history. With the default successful recovery, the latest increment was two, so compensation changes six to four and adds revision five with kind compensation. Earlier events remain visible; this does not delete history or undo a real tool call. If recovery has not caught up to the latest retained event, or durable history is unavailable, compensation is refused. Uncheck Inject process crash to inspect the uninterrupted run. The fixture assumes its checkpoints persist; it does not model partially written records, distributed transactions, storage corruption or external side effects.
Use every inspection control
Play reveals one modeled step every three inspection seconds at normal speed. Pause holds the displayed state, Next transition advances one boundary, and Restart returns to the opening state without changing parameters. Speed adjusts playback pace; the Time slider lets you examine any step, including the crash and recovery boundaries. Parameter edits recompute the entire fixed schedule and start playback; reduced-motion preference keeps the new run paused. Export replay JSON downloads this fictional configuration and full computed trace for comparison; it is not a backup of an actual agent session. Expand experiment opens fullscreen. Current snapshot provides exact text alongside the native-size diagram, which can be scrolled horizontally using the keyboard on narrow screens.
Interpret replay narrowly
The log stores committed counter values, revisions, actors and deltas. Recovery reuses recorded transitions after the checkpoint; it does not rerun worker code or invoke email, billing or other external services. Conflict count measures rejected compare-and-swap attempts in this chosen schedule. A larger final revision counts more accepted transitions, not better answer quality. Use the experiment to distinguish lost updates, missing checkpoints and missing replay, then consider separately how a real application atomically persists state and events. No account, database, cloud credentials or network service is accessed. All outcomes are deterministic local teaching data.