aws-cdk: (AwsCustomResource): fails to use latest SDK version
Describe the bug
When setting AwsCustomResource with installLatestAwsSdk: true it fails to upgrade aws-sdk to latest version (at this moment v3.556.0) and fails back to the default (currently v3.515.0 in Lambda).
Examples with DynamoDB:
INFO Installing latest AWS SDK v3: @aws-sdk/client-dynamodb
Task timed out after 120.10 seconds
.
.
.
INFO Installing latest AWS SDK v3: @aws-sdk/client-dynamodb
INFO Failed to install latest AWS SDK v3. Falling back to pre-installed version. Error: Error: Cannot find module 'mnemonist/lru-cache'
Require stack:
- /tmp/node_modules/@aws-sdk/endpoint-cache/dist-cjs/index.js
- /tmp/node_modules/@aws-sdk/middleware-endpoint-discovery/dist-cjs/index.js
- /tmp/node_modules/@aws-sdk/client-dynamodb/dist-cjs/index.js
- /var/task/index.js
- /var/runtime/index.mjs
.
.
and SSM modules:
INFO Installing latest AWS SDK v3: @aws-sdk/client-ssm
Task timed out after 120.16 seconds
.
.
INFO Installing latest AWS SDK v3: @aws-sdk/client-ssm
INFO Failed to install latest AWS SDK v3. Falling back to pre-installed version. Error: Error: Cannot find module '@smithy/shared-ini-file-loader'
Require stack:
- /tmp/node_modules/@smithy/node-config-provider/dist-cjs/index.js
- /tmp/node_modules/@smithy/middleware-endpoint/dist-cjs/adaptors/getEndpointFromConfig.js
- /tmp/node_modules/@smithy/middleware-endpoint/dist-cjs/index.js
- /tmp/node_modules/@smithy/core/dist-cjs/index.js
- /tmp/node_modules/@aws-sdk/client-ssm/dist-cjs/index.js
- /var/task/index.js
- /var/runtime/index.mjs
.
.
The custom resource eventually succeeds, after failing back to the default aws-sdk.
Expected Behavior
Be able to update the Lambda Nodejs18 runtime with the latest SDKv3 version.
Current Behavior
Unable to retrieve and upgrade Lambda Nodejs18 for SDKv3 latest version
Reproduction Steps
Deploy a CDK App with a Custom Resource that has installLatestAwsSdk: true:
const myTable = new dynamodb.Table(this, 'myTable', {
partitionKey: {
name: 'id',
type: dynamodb.AttributeType.STRING,
},
removalPolicy: cdk.RemovalPolicy.DESTROY,
});
const myCustomResource = new cr.AwsCustomResource(this, 'myCR', {
policy: cr.AwsCustomResourcePolicy.fromSdkCalls({
resources: cr.AwsCustomResourcePolicy.ANY_RESOURCE,
}),
installLatestAwsSdk: true,
onCreate: {
service: 'DynamoDB',
action: 'PutItem',
parameters: {
Item: {
id: {"S": 'test-value'}
},
TableName: myTable.tableName,
},
physicalResourceId: cr.PhysicalResourceId.of('myCRphysicalResourceID'),
},
onUpdate: {
service: 'DynamoDB',
action: 'PutItem',
parameters: {
service: 'DynamoDB',
action: 'PutItem',
parameters: {
Item: {
id: {"S": 'test-value'}
},
TableName: myTable.tableName,
},
physicalResourceId: cr.PhysicalResourceId.of('myCRphysicalResourceID'),
},
},
});
Check the underlying Lambda Function’s logs to see the messages above.
Possible Solution
No response
Additional Information/Context
No response
CDK CLI Version
2.137.0
Framework Version
No response
Node.js Version
18
OS
Mac
Language
TypeScript
Language Version
No response
Other information
No response
About this issue
- Original URL
- State: closed
- Created 2 months ago
- Reactions: 4
- Comments: 15 (8 by maintainers)
I’m also running into this, but in my case, the custom resource never succeeds.
This should be way more visible that it is tbh - it causes all my custom resources to fail, increasing the timeout is an option but very costly time wise. Since this is not fixed yest i just set the
install_latest_aws_sdk=Falseas suggested above. This thing costed my multiple hours of hair pulling today 😃I can confirm that increasing the timeout fixed this issue for me, too.
@colifran When I increase
timeoutsettings I have the same results you described. Now I believe it might be rather an issue with Lambda, not sure.It happens to any aws-cdk-lib version that provision functions with Nodejs18.x.
@frfavoreto @jakekarnes42 I did some more testing and it appears that the 2 minute default timeout that is set for
AwsCustomResourceis no longer sufficient for installing the latest SDK version. I set the default timeout to 5 minutes and this fixed the timeout issue for me. It looks like it took close to 4 minutes to install the latest SDK version. Would one of you be able to try this out on your end? I’ll continue testing this on my end.@frfavoreto , thanks for reaching out. Team is already Tracking this and working on it.