BucketNotificationsHandler failing for lambda version but no lambda in CDK code-CodePudding

I am trying to create a CloudFormation stack via CDK. I am creating a S3 bucket and listening its create notifications to a SNS.

But my CloudfFormation stack is failing with error:

The runtime parameter of nodejs10.x is no longer supported for creating or updating AWS Lambda functions. We recommend you use the new runtime (nodejs14.x) while creating or updating functions.

BucketNotificationsHandlerXXXXXXX

Resource handler returned message: "The runtime parameter of nodejs10.x is no longer supported for creating or updating AWS Lambda functions. We recommend you use the new runtime (nodejs14.x) while creating or updating functions. (Service: Lambda, Status Code: 400, Request ID: XXXXXX, Extended Request ID: null)" (RequestToken: XXXXXXX, HandlerErrorCode: InvalidRequest)

I am not sure from where this lambda error is coming into picture. And how can change its version, as I am not using lambda in this CDK.

Code part which am using in CDK:

    const snsOutput = new sns.Topic(this, 'snsOutput',
                {topicName: `snsOutput`});  // sns creation

    const S3Output = new Bucket(this, "S3Output", {
                    bucketName: `S3Output`,
                    blockPublicAccess: s3.BlockPublicAccess.BLOCK_ALL,
                    lifecycleRules: [{ expiration: Duration.days(3) }],
                    removalPolicy: RemovalPolicy.DESTROY,
                });  // s3 creation
    // creating event for s3 to sns
    S3Output.addObjectCreatedNotification(new s3n.SnsDestination(snsOutput));

CodePudding user response：

update your CDK version to the latest

CodePudding user response：

The answer given by theprince is the short answer.

The long answer is as follows: In order to be able to listen for incoming items and publish these events to the notification service, AWS autogenerates a default lambda (a singleton-lambda to be precise) that handles this for you. If you are in the lucky position of having a previous stack that actually did succeed before, you can view it via Cloudformation. Under the Resources tab you can see that there actually is a Lambda function present, something like 'BucketNotificationHandler'.

If you do not have a previous stack, then you can still view this. If you set up your cdk correctly, you must have done a 'cdk bootstrap'. This yields a small stack in your account with a comparable name, something like 'CDK Toolkit' or 'CDK Bootstrap'. If you look under this Cloudformation stack, under the Resources tab, you will find a bucket resource (typically named 'cdktoolkit-stagingbucket'). Click on the link to that bucket resource and you will get to an S3 bucket that your CDK uses to store Cloudformation changesets in the 'cdk' folder and zipped code files - if any - in the 'assets' folder. Click through to the 'cdk' folder. There you will find folders with the name of the stacks you have (attempted to) deploy(ed) which contain timestamped yaml files. Select the yaml file of which the timestamp most closely resembles the time at which you attempted your deploy and click on the 'Download' button at the top of the list. In this yaml file (file extension '.yml') you will see the cloudformation changeset that contains both all resources that you defined in your stack AND the autogenerated resources. (Needless to say: such file is best viewed in a code editor that can format yaml, such as VS Code).

Just search for the term 'nodejs' and you will quickly find resources that use nodejs as runtime, such as the aforementioned BucketNotificationHandler lambda that was autogenerated. You will most probably see something like this:

"Runtime": "nodejs10.x"

This is most probably a default nodejs version that your cdk version uses when it autogenerates lambdas. So upgrading to a newer CDK version will most probably increase the default nodejs version used for autogenerated lambdas.

So yes, give it a try and please let me know if this works (by marking this as an answer), because me and my colleagues are experiencing the same issue here, but we cannot simply upgrade to the new version at this moment, because we are dependent on a package that does not work with newer cdk versions. Hence the background research we did to make sure this is the actual problem at hand ;)