So here's an @awscloud Lambda@Edge problem that's haunted me for ages. A thread, as I thrash and attempt to learn the things I don't know...
Curling the official @awscloud status page takes .3 seconds to complete. If I curl stop.lying.cloud, that takes 23 seconds to complete. And it absolutely should not.
The domain points to a CloudFront distribution. That distribution invokes a Lambda function that returns HTML with my suitable modifications to the payload. 
"Okay Corey, you probably write code like crap."
Sure I do, but @epsagon shows that it's not the code that's hanging at all.
Sure I do, but @epsagon shows that it's not the code that's hanging at all.
Unfortunately I can't get tracing to work in edge Lambdas (they don't support layers) so I'm at a bit of a loss. Let's look at the CloudFront distribution logs.
Man are these wordy. Have yourself a little Github gist, as a treat: gist.github.com/QuinnyPig/cb77…
Given that it's over 20 seconds, it *feels* like there's a timeout that eventually gives up, returns what it has--and that renders as what I want. But I'm mystified as to where that's happening.
I’m gratified so far that everyone’s suggestions have been red herrings. I was kinda worried it’d be “a checkbox” or something. I may have to open an @AWSSupport ticket.
My assistant is almost as confused as I am.
Just to call this out explicitly: it's a near-certainty that the bug is on my side, either with code or configuration. I'd be *shocked* if this were @awscloud's fault in any meaningful way past "it's hard to observe what's going on with Lambda@Edge functions."
• • •
Missing some Tweet in this thread? You can try to
force a refresh
