RELIABILITY · REQUEST AND EFFECT INSPECTOR
Error recovery: know what the client cannot know
Follow one logical operation across repeated attempts, late responses, deduplication and committed server effects.
Your experiment
Choose a lost first response. Inspect the server commit before the client times out, then follow the retry that retrieves the stored result.
Inspect the committed counter, not only the client outcome. Change result retention to zero to explore what happens when a completed key is forgotten before another attempt arrives.
Recent events
Offline application-policy model, not an A2A/ADK retry contract or live API. One client intends one counter increment. Server operations continue after client timeouts. This server atomically reserves an in-flight key, then retains its result for the configured duration after commit. Response transit is fixed at 50ms; completed responses at an exact deadline are handled before timeout. Backoff doubles up to eight seconds; optional jitter uses a fixed illustrative sequence, not a production random generator. A 400 is non-retryable here; a first 503 is retryable. No crashes, durable storage, key-payload conflicts, multi-client retry storms or actual dead-letter broker are modeled. A retained intent is a reconciliation flag, not a guarantee of safe replay. Idempotency reference · Timeout and retry reference.
Recover an acknowledgment without repeating the effect
Use a lost first response, a stable intent key and enabled deduplication. Step through the first server commit, the client timeout, and the later retry. The stored result lets the retry acknowledge the original increment rather than perform another increment. Set retention to zero and repeat to expose the boundary: a forgotten completed key cannot provide that protection. Increase service time beyond the client timeout to inspect an in-flight duplicate instead of a completed-result hit.
Set the client and server independently
Fault selects normal success, lost success responses, an initial transient error, or rejected input. Server execution time (s) controls when a server operation commits. Timeout per attempt (s) controls how long each client attempt waits; it does not cancel server work. Maximum total attempts includes the first send, not just retries. Initial retry delay (s) sets the wait after a retryable failure, doubling on each further retry up to the model cap. Deterministic full-jitter example varies those delays with a fixed sequence, so comparisons stay reproducible rather than simulating a random population.
Choose what a retry identifies
Server deduplicates operation keys reserves an in-flight operation and reuses a retained result. Retry key either preserves one logical intent key or creates a new key for each attempt. A new key prevents this server from recognizing the same intent, even when deduplication is enabled. Stored-result retention (s) starts at commit and affects completed entries; it is disabled when deduplication is off. A retention of zero can let a later retry execute again. The model has no durable crash recovery or payload-conflict check, so its single-client result must not be presented as universal exactly-once delivery.
Read both sides of the timeline
The client-attempt panel shows sends and acknowledgments, the server panel shows operations, and the effect ledger counts committed increments. One increment is intended. Play and Pause inspect the sequence; Next event advances to an actual state transition, Restart rewinds, Speed changes inspection pace, and the timeline seeks to a chosen time. Editing a policy reconstructs the scenario. Read the final preview alongside the progressive trace: an exhausted client can coexist with a completed server effect, and an acknowledgment can arrive too late to change the client decision.