RELIABILITY · REQUEST AND EFFECT INSPECTOR
Retry identity: stable intent versus new keys
Follow one logical operation across repeated attempts, late responses, deduplication and committed server effects.
Your experiment
Enable deduplication but change the key on every attempt. Explain why the server cannot recognize the repeated intent. An A2A task identifier is not automatically this application idempotency key.
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.
Name the intent, not the attempt
Choose a lost-success-response fault and keep one stable intent key. With server deduplication and sufficient result retention, multiple client attempts can refer to one committed increment. Switch Key mode to a new key per attempt and compare the effect ledger: a new attempt identifier cannot deduplicate the earlier intent. An application intent key is not automatically interchangeable with a task identifier, which may represent execution state. This lab uses a counter effect rather than an actual task server so that duplicate execution is directly visible.
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.