ERROR PROPAGATION · CLIENT VERSUS SERVER
Failure propagation: client state versus server state
Charge one order through an orchestrator and a remote payments agent, inject a fault, and compare what the client believes with what the server committed.
Event trace
Computed data
Final metrics
Teaching model, not the A2A error schema or a payment API. Each hop takes 0.5 s; the orchestrator times out after 3 s and produces 504. The client treats only 400 as non-retryable and backs off exponentially. With a key, the payments tool returns the stored result for order 311 instead of charging again. Partial captures, refunds and network partitions between client and orchestrator are not modeled.
Paid twice for one order
Defaults: Injected fault Charge commits, response lost; Orchestrator error mapping Collapse every error to 500; 2 client retries; no key. Attempt 1 commits charge 1, but its response is lost and the orchestrator times out at 3.0 s, so the client receives 500. After a 1.0 s backoff, attempt 2 at 4.0 s commits charge 2: DUPLICATE CHARGE, client paid, 2 charges. Tick Idempotency key on the charge: the tool returns the stored result, CONSISTENT SUCCESS with 1 charge. The table shows, per attempt, the status produced, what the client received and the server effect.
When the client stops early
Without a key and with 0 retries, the collapsed 500 makes the client report payment failed while the server holds 1 charge: CLIENT-SERVER MISMATCH. With Preserve status and retryability the client sees 504 and reports OUTCOME UNKNOWN instead, which is honest. Report success with an empty result swallows the 504 and says paid; the ledgers agree only because the charge happened to commit, so the verdict is LUCKY MATCH.
Errors that must not be retried
Choose 400 invalid card. Collapsed to 500, the client retries a card that can never work: WASTED RETRIES, 3 attempts. Preserved, it stops after one: CONSISTENT FAILURE. Swallowed, the client shows paid while the server holds 0 charges: CLIENT-SERVER MISMATCH.
Rate limits and Retry-After
Choose 429 rate limit until t=4 s. Collapsed, the header is dropped and backoff alone retries at 1.5 s and 4.0 s: success on attempt 3. A First backoff of 0.5 s retries at 1.0 s and 2.5 s and fails all three, CONSISTENT FAILURE. With Preserve plus Client honours Retry-After, attempt 2 waits until 4.0 s and succeeds. 503 on the first attempt succeeds on attempt 2. Retry-After only helps when the orchestrator preserves the 429.
Replay and limits
Any change recomputes the run and rewinds it; the Complete-run preview states the outcome at once. Play and Pause walk through the events, Next event jumps one event, Restart rewinds, Speed runs from 0.25x to 2x and Inspection time seeks from 0 to 60 seconds, where the outcome and final metrics appear. Each hop takes 0.5 s, the orchestrator times out after 3 s, only 400 is non-retryable and backoff doubles per retry. This is a teaching model, not the A2A error schema or a payment API.