(@aws-cdk/aws-lambda): validate that layers must not be used with container functions

[ghost]

Although Lambda with Docker images does not support layers, one could set layers in CDK (used version 1.95.1). The official documentation for CDK 1.98.0 is still offering the construct prop (see https://docs.aws.amazon.com/cdk/api/latest/docs/@aws-cdk_aws-lambda.DockerImageFunction.html).

Using this option leads to an unsuccessful deployment with the following message in CFN:
Lambda layers are not supported for functions created with container images. (Service: AWSLambdaInternal; Status Code: 400; Error Code: InvalidParameterValueException; Request ID: 00f7e41e-d341-4a53-b67f-73cc6dbab507; Proxy: null)

Reproduction Steps

Define a Lambda function as below:
const myFunction = new lambda.DockerImageFunction(this, 'myDockerFunction', { code: lambda.DockerImageCode.fromImageAsset('./src/myFunctionCode/'), tracing: lambda.Tracing.ACTIVE, deadLetterQueueEnabled: true, memorySize: 1024, timeout: cdk.Duration.seconds(10), logRetention: 14 });

What did you expect to happen?

I expect that unsupported construct options are not implemented. This might lead to confusion during implementation when consulting the docs.

What actually happened?

For the error message of CFN, please see above.

Environment

• CDK CLI Version : 1.95.1 (tested), 1.98.0 still in docs and probably available
• Framework Version: 1.95.1 (tested), 1.98.0 still in docs and probably available
• Node.js Version: independend
• OS : independend
• Language (Version): all

---

This is 🐛 Bug Report

[nija-at]

Hi @RigoIce - thanks for filing this issue.

The best we can do here is to add a validation on the cdk side when layers are configured when using DockerImageFunction. That would mean you will get this error during synthesis and not have to wait until deployment.

Trying to model all the different combinations of properties allowed in the various scenarios will make the code hard to maintain.

[ghost]

Hi @nija-at. Thanks for taking care.

I understand the maintenance point of view. Having the build or even local synthesis failing before CFN complains would be very helpful as it could save a lot of time. Especially in migration phases as the options are so similar. As soon as one know this, it's okay. But anyways, I love when synthesis makes me aware of mistakes early. 😄

[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.

[annguyen36]

Hello team, although there is an error added to the synthesis step when creating container function with layers, I found the issue with addLayer() method when trying to add the layer to the container function, it was passed the synthesize
step and failed at stack deployment:

❌ Deployment failed: Error: The stack named DockerLayerStack failed to deploy: UPDATE_ROLLBACK_COMPLETE: Resource handler returned message: "Please don't provide Handler or Runtime or Layer when the intended function PackageType is Image. (Service: Lambda, Status Code: 400)" HandlerErrorCode: InvalidRequest)

doc: https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_lambda.DockerImageFunction.html#addwbrlayerslayers

Also, if the layers property is not suppose to be added to the DockerImageFunction construct, as well as the addLayer() method as this is something Lambda not support, why this listed under the CDK document as an available property of this construct?

This creates a lot of confusion, please consider to revise this document.