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
Error-handling patterns require classifying failures: transient timeouts and throttling are retryable with backoff; malformed poison payloads and permanent business rejects are terminal and should go to a dead-letter queue or explicit fail state. Retry-forever on all exceptions burns cost and blocks the workflow. Marking paid on error or masking failures as HTTP 200 corrupts business state and observability.