Skip to content

aws-lambda: Logical id of current version changes when upgrading form v2.87.0 to v2.88.0 #26739

@rehos

Description

@rehos

Describe the bug

I wanted to upgrade the CDK from 2.87.0 to 2.91.0 but ran into a deployment failure:

A version for this Lambda function exists ( 2 ). Modify the function to create a new version.

I was able to narrow it down to an unexpected change of the logical id of the resource generated for the current version of the lambda function when the lambda function has layers and you upgrade from version 2.87.0 to 2.88.0

Expected Behavior

When I only do a CDK version upgrade I don't expect the logical ids of any resource to change

Current Behavior

The logical id of the resource generated for the current version of the lambda function changes when the lambda function has layers and you upgrade from version 2.87.0 to 2.88.0...2.91.0

Reproduction Steps

Reproduce bug in aws-cdk-lib introduced between 2.87.0 and 2.88.0:

  1. Clone the repo
  2. Run npm install
  3. Run npm run cdk synth
  4. Open the generated template cdk.out/MyStack.template.json and notice the logical id of the lambda version is MyLambdaCurrentVersionE7A382CC40566d291e26de5fbeddf64c72bb9661
  5. Open package.json and change the version of both aws-cdk and aws-cdk-lib to 2.88.0
  6. Run npm install
  7. Run npm run cdk synth
  8. Open the generated template cdk.out/MyStack.template.json and notice the logical id of the lambda version is changed to MyLambdaCurrentVersionE7A382CC6466d36c9d15346e31eee2175be4ea3e

The change in logical id of the lambda version causes a deployment failure by CloudFormation because nothing has been changed to the lambda function nor the layer version.

Note: The logical id of the lambda version remains stable if the lambda function has no layers

Possible Solution

Make sure hash calculation functions sort (all) properties that are included in the hash first by name before calculating the hash to make the hash code independent from the generated cfnProperties function. And probably introduce a new feature flag for this new behavior.

Reason

The file packages/aws-cdk-lib/aws-lambda/lib/lambda.generated.ts for version v2.87.0 generated the properties for AWS::Lambda::LayerVersion in a different order than v2.88.0.

   // v2.87.0
    protected override get cfnProperties(): { [key: string]: any }  {
        return {
            content: this.content,
            compatibleArchitectures: this.compatibleArchitectures,
            compatibleRuntimes: this.compatibleRuntimes,
            description: this.description,
            layerName: this.layerName,
            licenseInfo: this.licenseInfo,
        };
    }

and

  // v2.88.0
  protected get cfnProperties(): Record<string, any> {
    return {
      "compatibleArchitectures": this.compatibleArchitectures,
      "compatibleRuntimes": this.compatibleRuntimes,
      "content": this.content,
      "description": this.description,
      "layerName": this.layerName,
      "licenseInfo": this.licenseInfo
    };
  }

Additional Information/Context

No response

CDK CLI Version

2.91.0

Framework Version

No response

Node.js Version

18

OS

Macos

Language

Typescript

Language Version

5.1.6

Other information

No response

Metadata

Metadata

Assignees

No one assigned

    Labels

    @aws-cdk/aws-lambdaRelated to AWS LambdabugThis issue is a bug.effort/mediumMedium work item – several days of effortp0

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions