- Newest
- Most votes
- Most comments
I have resolved my issue. It was to do with the amount of concurrent calls being made to my Lambda function. Reading online I saw that the AWS default for Lambda concurrent executions was 1,000 - so it didn't cross my mind to actually check that.
However, after digging and digging I found that my concurrent executions was in fact 10
Essentially meaning that if I ran the get API and more than 10 get requests occurred concurrently it would result in a rate limit, which I could see in CloudWatch Logs:
(daXXXd9d-92d92-4dwdc-bwad1-7ewaf9dwafc) Lambda invocation failed with status: 429. Lambda request id: c525XXXb8-9a54-4f2b-XXb0-7efXX7XX316a
(daXXXd9d-92d92-4dwdc-bwad1-7ewaf9dwafc) Execution failed due to configuration error: Rate Exceeded.
To resolve this I had to use **AWS Service Quota **and request an increase from 10 concurrent executions to something larger, in my case 50 which took a few hours to get approved.
As my WebApp works by sending a GET request for every image on the page the more images I added resulted in seeing the error more frequently which now makes sense. This has suggested my architecture is flawed and I should bundle my multiple GET requests into one single request to prevent this issue from occurring.
Since this change I have had no issues.
Hi,
Based on documentation: https://docs.aws.amazon.com/apigateway/latest/developerguide/supported-gateway-response-types.html
API_CONFIGURATION_ERROR 500
The gateway response for an invalid API configuration—including when an invalid endpoint
address is submitted, when base64 decoding fails on binary data when binary support is enacted,
or when integration response mapping can't match any template and no default template is
configured. If the response type is unspecified, this response defaults to the DEFAULT_5XX type.
Are you in one of those situations when it fails?
Best,
Didier
Relevant content
- asked a year ago
- AWS OFFICIALUpdated 7 months ago
- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated 2 years ago
I doubt it's the endpoint because its the same one every time (when it works vs when it doesn't). Can't be the base64 decoding because the error seems to be from the first get request which is only going to DynamoDB (not actually fetching the image) And again, I don't get how it could be the response mapping because its configured a way that works.
None of these error states really give me insight into why it would be intermittent...
Maybe it might spit out the error on the screen that makes it look like its the first get request issue, but could be fetching the binary data from S3?