Chapter 15
A timeout does not tell you whether a write happened
Updated
A CRM update times out after the remote system commits it. An agent retries.
Inspect
Locate the durable operation identifier, commit boundary, and status lookup. Determine whether a retry can be correlated with the first attempt and whether effects span multiple systems.
Decide
Choose an explicit contract for deduplication, reconciliation, and compensation. Bound retries within the overall deadline. Report an uncertain outcome when you cannot safely infer completion.
Bring to a review
A state diagram covering not started, in flight, committed, failed, and unknown; test a lost response after commit.
Common trap: Persisting the conversation or retry counter does not make the external effect exactly-once.
Read
- Designing robust and predictable APIs with idempotency A concrete integration pattern for retryable operations.Focus: Read request identifiers, server behavior, and retryable operations. Apply: Specify key scope, request-parameter matching, concurrent duplicate handling, and result retention.
- Timeouts, retries, and backoff with jitter Recover from partial failures without amplifying load or repeating side effects.Focus: Read timeout selection, retry amplification, backoff, and jitter. Apply: Give a dependency a time budget and bounded retry policy; identify the one layer responsible for retrying.
- 12-Factor Agents · Unify execution state and business state Understand the state that a resumable workflow must preserve.Focus: Read factor 5, then use the author-linked 12-Factor Agents talk as an alternative overview. Apply: Specify the persisted events needed to resume a paused task and reconcile any uncertain external side effect.