Eventbridge scheduler Synchronous Lambda invocations

0

Hi everyone,

I'm trying to use eventbridge scheduler to run my lambda synchronously and I'm receiving the error below. Someone know if this will be implemented soon ? I would like to give more power to eventbridge scheduler retries because as the comunication is asynchronous, eventbridg scheduler only fails if there is an infrastructure or overload issue. My idea for example is that eventbridge scheduler retries for an hour 50 times if my lambda function fails because there was a 500 http issue. I'm genereting the scheduler by aws-sdk v3, using universal targets to set "InvocationType: RequestResponse". See https://docs.aws.amazon.com/scheduler/latest/UserGuide/managing-targets-universal.html Thanks

{
    "name": "ValidationException",
    "$fault": "client",
    "$metadata": {
        "httpStatusCode": 400,
        "requestId": "4e696e3b-bca2-4400-8246-3b334749c8c1",
        "attempts": 1,
        "totalRetryDelay": 0
    },
    "message": "Invalid RequestJson provided. Reason Synchronous Lambda invocations are not yet supported. Please provide InvocationType parameter with value Event to invoke Lambda asynchronously."
}
1 Answer
3
Accepted Answer

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.

EXPERT
answered a year 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

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions