AWS Lambda Silent Crash – A Platform Failure, Not an Application Bug [pdf]

I didn’t bother to read this incredibly long write up past the introduction. But other commenters are asserting that the author expected their Lambda function to continue executing an async task after returning an HTTP response, despite numerous attempts by AWS staff to explain why that wouldn’t work. If true, that is _hilarious_. Easily one of the best stories of misguided anger/hubris/Dunning-Kruger I’ve ever heard. That’s like expecting a local function to continue executing after a `return` statement. It’s such a simple, basic principle of the platform they were trying to use.

But one thing bothers me…wouldn’t the author have encountered the exact same behavior in Azure? I guess I really will have to read this paper to find out.

They mentioned “rebuilding” in EC2. Probably just moved that over to Azure and no longer are bothering with serverless :)

I mean, they should just have created another queue, that triggers another lambda that then continues the process after the http response is sent.

However, it is still funny when you think that in regular servers you still finish when you respond to the request.

My dog keeps getting angry at the door. It won’t open automatically.

Azure functions don't operate in the same way, they are more like AppRunner's architecture. They then layer on the Lambda billing model.

It was typical Azure strategy of rushing out a product to show they have all the same features as AWS. It may have improved since I last touched it in 2018.

> That’s like expecting a local function to continue executing after a `return` statement.

Well... they can![1]

It's definitely a thing in traditional always-running web server processes, which is all people know these days.

Many developers have never written a code for a short-lived process outside of maybe school exercises. Things like CLI tools, background jobs, etc...

[1] I get "Later!" printed out... most of the time: https://dotnetfiddle.net/ng93d4

As of 2025 it's still very much the same.

Also, `defer` in go or `finally` in JS/Python