(@aws-cdk/aws-apigatewayv2): {message:"Internal server error",...}

[fr-an-k]

What is the problem?

A websocket message {message:"Internal server error",...} is returned when sending any message to a websocket, or when disconnecting. Only the $connect route works, and posting messages from the lambda function through the management API.

Adding the new @aws-cdk/aws-apigatewayv2-authorizers caused an error apparently related to a version conflict, so I upgraded the modules to 1.137.0, after which the issue started to occur. It worked before but had been abandoned while I worked on other parts in a local environment, so there might be other factors.

I reduced the stack to just a websocket API with 1 stage and trivial lambda integration on $connect/$disconnect/$default routes, but the issue persisted. The issue does not occur when you create such a setup through the AWS console.

Destroying/redeploying the stack several times, or downgrading the modules to 1.123.0 again, running yarn and destroying/redeploying did not resolve the issue. Also with 2.3.0 CLI and 1.137/1.123 modules.

In Custom Access Logging, I log pretty much everything, but there is no indication what causes the internal server error. The lambda handler never gets called.

The only hint of difference that I have is when you run:
aws apigatewayv2 get-integrations --api-id xx
The console-created API returns 3 (similar) integrations, while the CDK-created API returns 1; all like this:

{
            "ConnectionType": "INTERNET",
            "IntegrationId": "xx",
            "IntegrationMethod": "POST",
            "IntegrationType": "AWS_PROXY",
            "IntegrationUri": "arn:aws:apigateway:eu-central-1:lambda:path/2015-03-31/functions/arn:aws:lambda:eu-central-1:<accountid>:function:test123/invocations",
            "PassthroughBehavior": "WHEN_NO_MATCH",
            "PayloadFormatVersion": "1.0",
            "TimeoutInMillis": 29000
        }

Again, the console API returns an array with 3 of those objects, having only different integrationIds, while the CDK version returns only 1.

The issue happens in other stacks as well, but could be an AWS issue rather than CDK, even through it does not occur in a manual console API. I filed a case with premium support.

Reproduction Steps

I've reproduced it using this code:

index.js:

exports.handler = async (event) => {
    console.log(event)
    const response = {
        statusCode: 200
    };
    return response;
};

package.json:

{
  "name": "test123",
  "type": "module",
  "version": "0.1.0",
  "bin": {
    "test123": "bin/test123.js"
  },
  "scripts": {
    "cdk": "cdk"
  },
  "devDependencies": {
    "@aws-cdk/assertions": "1.137.0",
    "aws-cdk": "1.137.0"
  },
  "dependencies": {
    "@aws-cdk/aws-apigatewayv2": "^1.137.0",
    "@aws-cdk/aws-apigatewayv2-integrations": "^1.137.0",
    "@aws-cdk/aws-lambda-nodejs": "^1.137.0",
    "@aws-cdk/core": "1.137.0"
  }
}

bin/test123.js:

#!/usr/bin/env node

import {App} from '@aws-cdk/core'
import { Test123Stack } from '../lib/test123-stack.js'

const app = new App();
new Test123Stack(app, 'Test123Stack', {});

lib/test123-stack.js:

import { Stack } from '@aws-cdk/core'
import { WebSocketApi, WebSocketStage } from '@aws-cdk/aws-apigatewayv2'
import { WebSocketLambdaIntegration } from '@aws-cdk/aws-apigatewayv2-integrations'
import { NodejsFunction } from '@aws-cdk/aws-lambda-nodejs'

export class Test123 extends Stack {
  constructor(scope, id, props) {
    super(scope, id, props);
        const integration = new WebSocketLambdaIntegration(
            'id1',
            new NodejsFunction(this, 'id3', {
              handler: 'handler',
              functionName: 'id3',
              entry: 'index.js'
            })
        )
        const wsApi = new WebSocketApi(this, 'id2', {
          apiName: 'id2',
          connectRouteOptions: { integration },
          disconnectRouteOptions: { integration },
          defaultRouteOptions: { integration }
        })
        const wsStage = new WebSocketStage(this, 'id4', {
          stageName: 'production',
          webSocketApi: wsApi,
          autoDeploy: true
        })
  }
}

What did you expect to happen?

Be able to send websocket messages without issues, like before.

What actually happened?

Can't send messages from client to websocket lambda integration handler - code is only called on connect route.

CDK CLI Version

1.137.0 (build bfbdf64) and tried with 2.3.0 and 1.123.0

Framework Version

No response

Node.js Version

14.18.2

OS

Ubuntu 20

Language

Typescript

Language Version

ES 2020

Other information

No response

[fr-an-k]

I've reproduced the issue with the code updated above, CLI version 1.137.0.

Then get the wss endpoint or API id from API Gateway and use something like:

wscat -c wss://abc123.execute-api.eu-central-1.amazonaws.com/production

Then enter a message and receive:

{"message": "Internal server error", "connectionId":"...", "requestId":"..."}

[fr-an-k]

I've also reproduced it with cli version 2.3.0 and the following changes in imports:

test123-stack.js

import { Stack } from 'aws-cdk-lib'
import { WebSocketApi, WebSocketStage } from '@aws-cdk/aws-apigatewayv2-alpha'
import { WebSocketLambdaIntegration } from '@aws-cdk/aws-apigatewayv2-integrations-alpha'
import { NodejsFunction } from 'aws-cdk-lib/aws-lambda-nodejs'

test123.js

import {App} from 'aws-cdk-lib'

  "devDependencies": {
  },
  "dependencies": {
    "@aws-cdk/aws-apigatewayv2-alpha": "^2.3.0-alpha.0",
    "@aws-cdk/aws-apigatewayv2-integrations-alpha": "^2.3.0-alpha.0",
    "aws-cdk-lib": "^2.3.0",
    "constructs": "^10.0.17"
  }

[fr-an-k]

Figured it out; apparently you now have to make an integration per route when using the same function for all routes.

[github-actions]

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.

[ppena-LiveData]

Why is this ticket closed? "you now have to make an integration per route when using the same function for all routes" sounds like a workaround to a bug and isn't a real fix to a bug. This used to work in CDK v1. Now in CDK v2, when I look at the CloudFormation template that CDK creates, v2 is creating the AWS::ApiGatewayV2::Route with the appropriate Target to the Lambda, but it only creates a AWS::Lambda::Permission for the lambda:InvokeFunction for the first route, not the subsequent routes. In CDK v1, the permissions were correctly added for all routes.

BTW, I see that this issue was partially fixed. It was fixed for HttpApi but not for WebSocketApi.

[emilianomongelo]

Any updates on this?

[osw-au]

update this pls