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.
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.
The comments here are focusing on the code description by the author, of code he did not post, and the confusing explanations of the author, while ignoring the incorrect but demonstrative test case from AWS.
If you talk about documentation, and in this thread there have been many mentions of it, without citing specific paragraphs, we could start with this one from here [1]:
"Using async/await (recommended)"
"...The async keyword marks a function as asynchronous, and the await keyword pauses the execution of the function until a Promise is resolved..."
Or
"Using callbacks"
"...The function continues to execute until the event loop is empty or the function times out. The response isn't sent to the invoker until all event loop tasks are finished. If the function times out, an error is returned instead. You can configure the runtime to send the response immediately by setting context.callbackWaitsForEmptyEventLoop to false..."
It actually seems, the most likely that happendd here, were random disconnects from the VPC, that neither the author or AWS support were able to contextualize.
That’s the whole point and it’s not the behavior your comments describe.