A Step Functions-style intake flow needs distinct handling for poison messages versus retryable timeouts when calling a payment gateway. What should developers do?
Select an answer to reveal the explanation.
Short Explanation
A timeout is a maybe; a poison message is a no. Treat them differently — retry the maybe with backoff, park the no on a DLQ or fail state. One-size-fits-all retries just spin poison forever.
Full Explanation
A Step Functions-style intake flow needs distinct handling for poison messages versus retryable timeouts when calling a payment gateway. Developers should classify errors as retryable versus terminal: retry timeouts with backoff, and route poison or permanent failures to a DLQ or fail state. Timeouts and 503s often succeed later; malformed payloads, invalid account states, or non-retryable business declines will not. Treating them alike either spins forever or drops recoverable work.
Catching every exception with the same retry-forever policy never surfaces poison for remediation and burns cost. Ignoring payment errors and marking licenses paid corrupts municipal revenue and audit trails. Collapsing all failure types into HTTP 200 hides incidents from clients and operators.
Exam caveat: in Step Functions, use Retry for transient error equals and Catch toward Fail or parallel DLQ notification for terminal faults. Idempotency remains mandatory because successful payment plus a later timeout retry can double-charge without safeguards.
Operational check: taxonomy payment errors into retryable vs terminal; configure per-state retries with backoff ceilings; send poison to DLQ/fail with case ID; and require finance playbooks for DLQ replay after fixing data.