RELIABILITY · REQUEST AND EFFECT INSPECTOR
Error handling: classify before retrying
Follow one logical operation across repeated attempts, late responses, deduplication and committed server effects.
Your experiment
Compare a first-attempt 503 with a 400 invalid-input response. This application policy retries the former but stops immediately on the latter.
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.
Classify a failure before retrying
Compare the first-attempt 503 with the 400 invalid-input condition. With the default attempt budget, the transient failure allows another attempt; invalid input stops under this application policy. Then lose the first success response instead. Its symptom is a client timeout, but the server has already committed. A dashboard showing only client status would miss that difference. Use the ledger and event trace to distinguish rejected input, transient availability, and uncertain acknowledgment of a real effect.
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.