Unexpected LAMBDA_RUNTIME Failed to post handler success response. Http response code: 413 error

Unexpected LAMBDA_RUNTIME Failed to post handler success response. Http response code: 413 error


14

So I have a serverless express application running in a Lambda. One request (response size around 800KB) keeps returning a LAMBDA_RUNTIME Failed to post handler success response. Http response code: 413. error.
I thought it could be due to some internal logic timing out, and added logs, and all the fetch and processing takes maximum 6 seconds, but the lamdba still returns this error.

These are the response headers

x-amz-cf-pop: YTO50-C3
x-amzn-errortype: InternalServerErrorException
x-amzn-requestid: f291230-342-4324-324-cb7df188944c
x-cache: Error from cloudfront

The response size is definitely not too big, I am returning a response with right data, no errors are being thrown in the logs. Any idea why this could be happening? Also any suggestions on how I can debug this issue? Everything of course works in local, but is there a way for me debug the actual lambda? The logs I added indicate that the full process completes, yet somehow there is an error being returned.

Updated my serverless.yml config

service: my-service
variablesResolutionMode: 20210326
useDotenv: true

custom:
  serverless-offline:
    useChildProcesses: true
  webpack:
    webpackConfig: ./webpack.config.js
    packager: "yarn"
    includeModules: true
  prune:
    automatic: true
    includeLayers: true
    number: 3
  customDomain:
    domainName: "abc.com"
    basePath: "val"
    stage: ${someval}
    createRoute53Record: true

plugins:
  - serverless-domain-manager
  - serverless-webpack
  - serverless-prune-plugin
  - serverless-webpack-prisma
  - serverless-offline

provider:
  lambdaHashingVersion: "20201221"
  name: aws
  runtime: nodejs14.x
  region: us-east-1
  timeout: 30
  apiGateway:
    minimumCompressionSize: 1024 
  iamRoleStatements:
    - Effect: Allow
      Action: ssm:Get*
      Resource:
        - "abc/${opt:stage}/backend/*"
        - "abc/${opt:stage}/services/*"
    - Effect: Allow
      Action: kms:Decrypt
      Resource: "*"
    - Effect: "Allow"
      Action: s3:PutObject
      Resource: "abc/*"
    - Effect: "Allow"
      Action:
        - sns:Publish
      Resource: "*"

  environment:
    - myvars: 'abc'

functions:
  graphql:
    handler: src/index.graphqlHandler
    events:
      - https:
          path: /graphql
          method: options
      - https:
          path: /graphql
          method: get
      - https:
          path: /graphql
          method: post

3

  • This appears to be from CloudFront, not Lambda. I'd look into CloudFront logging to understand why CloudFront is failing. You're nowhere near the 30GB limit of CloudFront.

    – stdunbar

    Aug 16, 2022 at 20:07

  • @stdunbar – I'm not an expert so please excuse the ignorance, but I don't actively have Cloudfront set up, I cannot find any reference to it in my Cloudformation resources either. How would I go about debugging this? Also this is happening with a single request and the Lambda is throwing the error, I can see it in Cloudwatch.

    – kvnam

    Aug 16, 2022 at 20:25

  • According to this blog using your own domain with serverless-domain-manager creates that for you. This is part of the requirement to have a custom domain in front of API Gateway with or without the serverless framework. Why it's failing though is still unclear. I can only tell you to turn on logging – I'm not positive how to debug it other than logging in the Lambda how big of a response you're sending.

    – stdunbar

    Aug 16, 2022 at 20:35


2 Answers
2


21

This error is usually due to hitting the Lambda limit for response payload.

Currently, AWS Lambdas have a hard limit for invocation payloads of:

  • 6MB for Synchronous requests and
  • 256KB for Asynchronous requests,

According to the documentation:

Unexpected LAMBDA_RUNTIME Failed to post handler success response. Http response code: 413 error


https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html

Keep in mind that this is a hard limit and cannot be increased.

Currently (2022), if you need more than this limit, you’ll have two options that I can think of

  1. use another stack, for example ECS
  2. you can compress (gzip, brotli, etc) your response inside the lambda and uncompress in the consumer. If you’re using API Gateway to expose your lambda, you’ll have to set the appropriate header.

Personally, I’ve experienced similar issues even before reaching this threshold, so it can be hard to calculate exactly the size of your payload.

1

  • 1

    Wow, great answer. Too bad the error messages or logs or some part of the Lambda didn't actually just say "payload total greater than 6MB". Ugh. For the record, apparently unbufferred payloads have a soft limit of 20mb as quoted in the lambda quotas, so that's an option if someone needs that functionality.

    – Rickaroo

    Oct 9 at 21:35


0

Yeah. This error is related to the 6MB size limitation for request and response between kinesis firehose and lambda function.

https://docs.aws.amazon.com/firehose/latest/dev/data-transformation.html

my solution to this issue. Create a get_size function, check the message size one by one and added together as total_size, if total_size > 6 * 1024 * 1024 – 1 (6MB), add the extra message to send_back_list. Then at last, send all extra message send_back_list to the kinesis firehose again to ingest the missing data.



Leave a Reply

Your email address will not be published. Required fields are marked *