Async Lambda Event Sources #1352
Conversation
…(default behavior is now async).
|
Thanks @efritz - this sounds like a reasonable proposal to me. However, it seems that there are a number of tests currently failing which probably make the assumption that Lambdas are executed synchronously. I guess we'd have to dig into each of these cases and figure out if the assumptions in the tests are valid or not, and then fix the behavior accordingly. I'd be happy to provide guidance, but would you be able to take over the lead on this task? Thanks! |
|
When running locally, |
|
@efritz Would love to revisit this PR. It seems that the functionality in this PR is (partly) covered by #1973 , at least as far as SNS triggered Lambdas are concerned. Can we try to rebase to I think it should now (hopefully) also be easier to get the tests working. If you are not planning to make these changes, I can try to take over this PR and take a stab at it. Thanks |
|
Sure, I’ll take another look this weekend. |
|
Looks like it didn't help the automated tests all that much :/ |
To speed up local actions and to be a bit closer to production behavior, lambda events triggered by an event source should be done so asynchronously.
This change makes async processing the default behavior, but allows each service (API Gateway, SNS, Kinesis, DyanmoDB, and SQS) to turn on synchronous processing with environment variables.
This may be a short-sighted change, but I can't see a major reason for synchronous processing to be blocking by default - please let me know if I'm missing a use-case.
This change is necessary as I'm using a custom go1.x runtime image that only allows on event to be processed at a time (simulating a reserved concurrency of one), and synchronous events deadlock if a dynamodb handler publishes a record back to dynamodb. Setting them as async does exactly what we're looking for.