Lambda Error Handling and Response Management
Job-processing lambdas return success when execution completes normally; the job's outcome travels in the response payload, not as a thrown error.
Install in Blint
Opens the Blint desktop app and adds this pattern to your project. Don't have Blint?
Predictable failures (network timeouts, missing resources, validation errors) are operational states, not execution failures. Only surface errors for unexpected runtime failures (crashes, uncaught exceptions). A thrown error tells the invoking infrastructure to retry: the queue redelivers the message — and on a FIFO queue the failing message blocks its entire message group, starving everything queued behind it.
Rules
- Always return success if the lambda invoked without crashing, even when the underlying job fails.
- Never return errors for predictable failures (network issues, missing data, invalid inputs). Log them and return success.
- Use the response payload to communicate job status — include success/failure flags and error details in the returned data structure, not HTTP status codes.
- Let the invoking system (queue redrive, DLQs, application-level recovery jobs) own retries and recovery logic rather than implementing exponential backoff or retry loops inside the lambda.
- Only return errors when the lambda itself fails (uncaught exception, out of memory, timeout), not when the task it performs fails.