Most workflow failures are not “the API returned 500.” The expensive failures happen when nobody knows whether the last step succeeded.
If an n8n or custom API workflow moves money, updates a CRM, sends a message, or creates a record, test these eight paths before calling it production-ready.
1. Duplicate delivery
Assume every webhook can arrive twice. Use a stable event or operation ID and make the second delivery a no-op with a recorded outcome.
Test: replay the identical payload concurrently and verify exactly one side effect.
2. Timeout after the provider succeeded
A client timeout does not prove the remote operation failed. Blind retrying can create duplicate charges, tickets, or notifications.
Rule: after an ambiguous timeout, reconcile by idempotency key or provider lookup before retrying the side effect.
3. Partial local write
The provider succeeds, but your database update fails—or the reverse.
Rule: store an explicit state transition such as requested -> provider_confirmed -> locally_applied, with a repair path for every non-terminal state.
4. Stale or revoked credentials
Refresh logic often works in isolation and fails under concurrency.
Test: expire the token, run several executions at once, and confirm there is one refresh attempt rather than a refresh storm.
5. Retry storm
Retries without a cap, backoff, jitter, and dead-letter state can turn one provider incident into your own outage.
Record: attempt count, next retry time, last error class, and terminal disposition.
6. Out-of-order events
“Created,” “updated,” and “cancelled” events may not arrive in order.
Rule: apply version checks or state-transition guards. Never let an older event silently overwrite newer truth.
7. Poisoned payload
One malformed item should not block an entire batch forever.
Test: mix one invalid item into a valid batch. Verify the good items finish and the bad item reaches a visible quarantine/dead-letter path.
8. Human replay
Operators need a safe way to inspect and replay a failed execution without reproducing already-completed side effects.
Require: a correlation ID, current state, prior provider response, proposed next transition, and an idempotent replay action.
A practical review artifact
For one integration boundary, write a table with:
- failure trigger
- observable evidence
- current state
- allowed retry
- idempotency key
- recovery action
- terminal state
- test case
That table catches more production risk than another happy-path screenshot.
I offer a fixed-scope $99 Integration Failure-Path Diagnostic for one n8n/API/provider boundary: risk matrix, retry/state-transition rules, patch plan, and failure-path tests, delivered in two business days. The fee is credited toward a $299 implementation patch.
Top comments (0)