EMAIL TOOL · RECEIPTS VERSUS DELIVERIES
Email observability: receipt versus repeated delivery
Send four emails through a slow provider with a tool timeout, retries and idempotency keys, then compare reported status with what customers received.
Your experiment
The provider takes 6 s to accept the invoice email M2, longer than the 5 s tool timeout, but it still delivers it. Start with a retry under a new key and status from the tool return, then reuse the key, drop the retry, switch to webhooks and change the timeout.
Play replays the computed run over sixty inspection seconds; Next event steps, Restart rewinds, Speed changes the pace and Inspection time scrubs. Any input change recomputes the run and rewinds it without autoplay.
Event trace
Computed data
Final metrics
Deterministic model of one provider: acceptance latency is fixed per message, an accepted message is always delivered, a retry is accepted in 1 s, and webhooks report every delivery. Real providers add bounces, deferrals, rate limits and key expiry windows. Addresses and messages are fictional; nothing is sent.
A timeout is not a failure
The agent sends four emails. The provider accepts M1 in 1.2 s, M2 the invoice in 6 s, M3 in 0.8 s and M4 in 3.5 s, and delivers every accepted message even if the caller stopped waiting. With a 5 s Tool timeout the call for M2 times out while the provider is still accepting it. The opening policy retries once with a new idempotency key, so the provider accepts a second invoice: 5 emails delivered for 4 intents, DUPLICATE DELIVERY. The tool return value reports 4 sent, so the log looks clean while one customer has two invoices.
Reuse the key, and make sure it is honored
Set Retry after a timeout to Once, with the same idempotency key. The provider recognises the key and returns the original receipt, so the result is ONE EMAIL PER INTENT with 4 delivered and 4 reported. Provider deduplicates idempotency keys matters only for this same-key retry: clear it and the retry is treated as a new message, 5 delivered. A retry is safe only when the receiver deduplicates on a key that stays the same across attempts.
No retry misreports instead of duplicating
Choose No retry. Every customer gets exactly one email, but the tool return for M2 says failed, so 3 are reported for 4 delivered: STATUS MISREPORTED. An agent that trusts that return value may apologise for an invoice the customer already has, or a human may resend it by hand. Set Status recorded from to Provider delivery webhooks and the report matches the deliveries: 4 of 4.
Where the timeout sits
Raise Tool timeout to 10 s and every call returns in time: nothing to retry, 4 delivered. Lower it to 1 s and M1, M2 and M4 all time out; with a new key per retry that becomes 7 emails for 4 intents, while a same-key retry still yields 4. Webhooks report every delivery, including duplicates: with a new-key retry they show 5 reported for 5 delivered, which is accurate observation of a duplicate, not a fix for it.
Reading the run and its limits
Play, Next event, Restart, Speed and Inspection time step through each message, the timeout, the retry and the reconciliation across sixty seconds; the delivery and status lanes turn red where they disagree with one email per intent. The provider in this model always delivers what it accepts, retries are accepted in 1 s, and keys never expire. Real providers bounce, defer and rate-limit messages, and keep idempotency keys only for a limited time.