Describe the bug
In the v3 SDK, lambda response payloads are now encoded as a uint8array -- which can break some implementations e.g. using AwsCustomResource to invoke a lambda function and then attempting to read the payload
Having a stack like this worked on versions before AwsCustomResource updated to SDK v3, like 2.75.0:
const fn = new lambda.Function(this, "Function", {
code: lambda.Code.fromInline("exports.handler = async () => { return { statusCode: 200, body: 'Hello World' }; };"),
handler: "index.handler",
runtime: lambda.Runtime.NODEJS_16_X,
});
const listLambdaFunctionsResource = new cr.AwsCustomResource(this, 'ListLambdaFunctions', {
installLatestAwsSdk: true,
onUpdate: {
service: 'Lambda',
action: 'invoke',
parameters: {
FunctionName: fn.functionName,
},
physicalResourceId: cr.PhysicalResourceId.of(Date.now().toString()),
},
policy: cr.AwsCustomResourcePolicy.fromStatements([
new iam.PolicyStatement({
actions: ['*'],
resources: ['*'],
effect: iam.Effect.ALLOW,
})
]),
});
const lambdafunctions = listLambdaFunctionsResource.getResponseField('Payload').toString();
new cdk.CfnOutput(this, 'LambdaFunctions', {
value: lambdafunctions
})However, it will end up failing on a newer version where the AwsCustomResource is updated to SDK v3 like 2.90.0. Checking the CloudTrail logs, you can see that the payload returned looks like this instead of what you would normally expect:
"Data": {
"region": "us-east-1",
"$metadata.httpStatusCode": 200,
"$metadata.requestId": "f8d6dc59-7cfc-4be7-bf21-7753b3c17636",
"$metadata.attempts": 1,
"$metadata.totalRetryDelay": 0,
"ExecutedVersion": "$LATEST",
"Payload.0": 123,
"Payload.1": 34,
"Payload.2": 115,
"Payload.3": 116,
"Payload.4": 97,
"Payload.5": 116,
"Payload.6": 117,
"Payload.7": 115,
"Payload.8": 67,
"Payload.9": 111,
"Payload.10": 100,
"Payload.11": 101,
"Payload.12": 34,
"Payload.13": 58,
"Payload.14": 50,
"Payload.15": 48,
"Payload.16": 48,
"Payload.17": 44,
"Payload.18": 34,
"Payload.19": 98,
"Payload.20": 111,
"Payload.21": 100,
"Payload.22": 121,
"Payload.23": 34,
"Payload.24": 58,
"Payload.25": 34,
"Payload.26": 72,
"Payload.27": 101,
"Payload.28": 108,
"Payload.29": 108,
"Payload.30": 111,
"Payload.31": 32,
"Payload.32": 87,
"Payload.33": 111,
"Payload.34": 114,
"Payload.35": 108,
"Payload.36": 100,
"Payload.37": 34,
"Payload.38": 125,
"StatusCode": 200
}Expected Behavior
I expected the resource to have readable properties like this being returned from the custom resource as it did prior to the update:
"Data": {
"apiVersion": null,
"region": "us-east-1",
"StatusCode": 200,
"ExecutedVersion": "$LATEST",
"Payload": "{\"statusCode\":200,\"body\":\"Hello World\"}"
}
Current Behavior
The resource's returned properties aren't parseable
Reproduction Steps
See description
Possible Solution
No response
Additional Information/Context
No response
CDK CLI Version
2.90.0
Framework Version
No response
Node.js Version
16
OS
Mac
Language
Typescript
Language Version
No response
Other information
No response
Describe the bug
In the v3 SDK, lambda response payloads are now encoded as a uint8array -- which can break some implementations e.g. using AwsCustomResource to invoke a lambda function and then attempting to read the payload
Having a stack like this worked on versions before AwsCustomResource updated to SDK v3, like
2.75.0:However, it will end up failing on a newer version where the AwsCustomResource is updated to SDK v3 like
2.90.0. Checking the CloudTrail logs, you can see that the payload returned looks like this instead of what you would normally expect:Expected Behavior
I expected the resource to have readable properties like this being returned from the custom resource as it did prior to the update:
Current Behavior
The resource's returned properties aren't parseable
Reproduction Steps
See description
Possible Solution
No response
Additional Information/Context
No response
CDK CLI Version
2.90.0
Framework Version
No response
Node.js Version
16
OS
Mac
Language
Typescript
Language Version
No response
Other information
No response