←back to thread

115 points nonfamous | 1 comments | | HN request time: 0.406s | source
Show context
johnduhart ◴[] No.44567380[source]
Oh wow, a 23-page write up about how the author misunderstood AWS Lambda's execution model [1].

> It emits an event, then immediately returns a response — meaning it always reports success (201), regardless of whether the downstream email handler succeeds or fails.

It should be understood that after Lambda returns a response the MicroVM is suspending, interrupting your background HTTP request. There is zero guarantee that the request would succeed.

1: https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtime-...

replies(4): >>44567460 #>>44568625 #>>44568884 #>>44573721 #
belter ◴[] No.44573721[source]
Uhhmm… it seems both you and @frenchtoast8 are misrepresenting the code flow. The author doesn’t return early, the handler is async and explicitly awaits an https.request() Promise. The return only happens after the request resolves or fails. Lambda is terminating mid-await, not post-return.

That’s the whole point and it’s not the behavior your comments describe.

replies(2): >>44573944 #>>44574790 #
Scaevolus ◴[] No.44573944[source]
Page 5: "It emits an event, then immediately returns a response — meaning it always reports success (201), regardless of whether the downstream email handler succeeds or fails."

This is not the right way to accomplish this. If you want a Lambda function to trigger background processing, you invoke another lambda function before returning. Using Node.js events for background processing doesn't work, since the Lambda runtime shuts down the event loop as quickly as possible.

replies(1): >>44575264 #
1. ◴[] No.44575264[source]