Step 4
Step 4 — Handle Timeout, Unknown, Retry, and Reconcile
0 views
Step 4 — Handle Timeout, Unknown, Retry, and Reconcile
An external 200 OK does not always mean that our business operation is complete. Hide provider vocabulary behind an adapter and preserve the case where the effect is unknown.
- Timeout: our waiting budget expired.
- Unknown: we do not yet know whether the external effect happened.
- Retry: one owner decides which error, how many attempts, and what backoff.
- Reconcile: lookup, webhook, or a comparison job converges our state with external facts.
One layer must own retries. If both the HTTP client and scheduler retry three times, load and duplicate effects multiply. Permanent errors stop; transient errors use a cap and jitter.
Warragon's Python crawlers separate requeueable transient failures from permanent failed records. Kafka has retry/DLQ boundaries, and FCM/AI outcomes do not silently turn a successful database write into a claimed delivery success.
Show accepted, processing, needs confirmation, and failed states. A user should know whether pressing again is safe.