- Newest
- Most votes
- Most comments
As always AWS won't make their release timeline visible other than very rough roadmap plans in Partner briefings etc. I wouldn't hold my breath on this one - synchronous invocation is more about getting a result back to the caller and being able to retry on application errors. On the other hand you want to retry because of infrastructure/overload errors so I think you should look at another approach.
Lambda supports Maximum Event Age and Maximum Retry Attempts for asynchronous invocations.
Failed events can be sent to a DLQ; they contain the original event payload plus RequestID, ErrorCode (3-digit HTTP error code) and ErrorMessage (truncated to 1KB).
Lambda Destinations for asynchronous invocations provides visibility into Lambda function invocations and routes the execution results to AWS services. Async invocations are queued, and results can be sent to Lambda, SQS, SNS or EventBridge, separately for Success/Failure. So this gives you more options to extend your retries if the max event age & retry attempts settings above don't cover it.
You could also use Step Functions though Lambda Destinations is probably a better and cheaper solution. With Step Functions you could use the Callback Pattern with a heartbeat timeout; if your lambda doesn't send back a token to say it's run, then the heartbeat timeout allows you to invoke asynchronously again for another set of retries.
Relevant content
- asked a year ago
- asked 4 months ago
- asked a year ago
- asked a year ago
- AWS OFFICIALUpdated a year ago
- AWS OFFICIALUpdated a year ago
- AWS OFFICIALUpdated 7 months ago
- AWS OFFICIALUpdated 8 months ago
Hi @skinsman for your replay. Lambda retries are not enough (only 2 retries max) for my use case. Eventbridge scheduler seems to be crooked on this. Because I'm rookie on AWS I didn't know about step functions but seems to fit on my solution. Thanks you