RELIABILITY · REQUEST AND EFFECT INSPECTOR
Dead-letter intent: reconcile an uncertain outcome
Follow one logical operation across repeated attempts, late responses, deduplication and committed server effects.
Your experiment
Lose all responses and inspect the retained intent after retries are exhausted. Compare server effects before deciding whether replay would be safe. This lab does not automatically replay it.
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.
Reconcile before replaying
Choose lost responses for every attempt, retain deduplication results for thirty seconds, and keep the intent key stable. The server can increment once while the client exhausts its attempts and retains an unresolved intent. Disable deduplication and compare the increment count. The retained flag says that someone must reconcile intent with effects; it is not a safe replay button or an implemented message broker. Record both the exhausted client state and the committed counter before deciding what an operational recovery procedure would need to verify.
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.