Why timeout handling matters
Transport failure tells you the caller did not receive a usable response. It does not tell you whether the provider committed the external effect.
Safer recovery
Keep the original logical-operation identity, inspect durable operation state and reconcile provider truth where supported. If safety cannot be established, preserve uncertainty instead of guessing.
Run the failure yourself
Minimal failure: send one refund; the provider commits; lose the response; retry after restart. A new request without effective deduplication can create another refund.
// Unsafe when the first refund may already have committed:
try { await refundCustomer(intent); }
catch { await refundCustomer(intent); }Use the runnable local refund proof: a separate HTTP provider records two unprotected effects versus one with Once, followed by UNKNOWN blocking, authoritative reconciliation and changed-amount CONFLICT. No financial account is required.
When an idempotency key solves it
If the provider key binds the complete intended operation for your full retry horizon, use it. Once does not replace that guarantee. A local result table cannot make an arbitrary external write atomic with a database commit; preserve uncertainty when no trustworthy result exists.
Limits and next action
The controlled proof is not a real payment integration. Your developer must explicitly choose a stable, tenant-scoped refund-intent ID and complete effect/account fields. Use distinct IDs for genuine new partial refunds. UNKNOWN stays blocked when truth is unavailable; absence alone does not authorize local redispatch. Local SQLite is limited to one machine.