(@aws-cdk/aws-apigatewayv2): {message:"Internal server error",...}
See original GitHub issueWhat 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
Issue Analytics
- State:
- Created 2 years ago
- Comments:6
Top GitHub Comments
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 appropriateTarget
to the Lambda, but it only creates aAWS::Lambda::Permission
for thelambda: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 forWebSocketApi
.Any updates on this?