Open vinczedani opened 2 years ago
This would be expected given the AWS lambda runtime. The process got suspended and you had a timeout for a response. I think you'll have to catch with this error and retry the call.
So you say it is not possible to just wait infinitely for a possible response? I might not remember correctly but I think when using the https library in Node I was able to pass in timeout infinity and never see similar problems. I think when AWS shots down my lambda process it totally kills it, when when running it again for the first time after some delay, it boots up a new container from the image. In that case the code (in theory) should work as for the first invocation (when it succeeds)
Try catch + retry should work, I just wanted to avoid it, if its possible to solve it with passing an option parameter
Lambdas do have a limit on execution time: https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html#function-configuration-deployment-and-execution 900seconds.
Seeing the same issue, was not happening using node16 with node-fetch, and now a high % of my lambda extension fetch calls fail.
Bug Description
Hello, I'm trying to create a custom AWS lambda container runtime as a small hobby project. And since fetch is now part of the core NodeJS I wanted to give it a try. To get the lambda invocations, I need a request with a really long timeout, so I did set up an AbortController that will never be triggered:
When I uploaded my code to aws (as a container image). And tested it, the first execution was fine, but after a few minutes I retried and got:
Reproducible By
Full snippet of my test code:
Expected Behavior
If the abort controller is never triggered, I'd expect to never receive a timeout error.
Logs & Screenshots
Environment
I uploaded the above code to AWS ECR and ran it in lambda as container image. My dockerfile is
Additional context