RELIABILITY · REQUEST AND EFFECT INSPECTOR
Timeouts: waiting ends, server work may continue
Follow one logical operation across repeated attempts, late responses, deduplication and committed server effects.
Your experiment
Choose no response fault, set service time to eight seconds and timeout to one. Observe server completion after client attempts have timed out.
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.
A client timeout does not undo a server commit
Choose normal success with a service time of five seconds, client timeout of one second, one allowed attempt and server deduplication enabled. Inspect the timeout first: the client has exhausted its budget, but the server operation remains running. Continue to the commit at model second five (the time readout shows inspection seconds and model seconds side by side) and observe one increment despite the failed client outcome. No cancellation message is sent. Increase the attempt budget while retaining the stable key to observe retries attach to the same in-flight intent; disable deduplication to expose multiple server operations. The model tracks commit time and acknowledgment separately, so an unavailable response is not falsely presented as proof that nothing happened.
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.