(aws-cdk-lib.aws_lambda): Lambda alias/version not updated with tokenized env var

[enpatrik]

Describe the bug

When using tokenized input as a environment variable value, the Lambda alias is not automatically updated.

Expected Behavior

A new Lambda version to be created and the Lambda alias updated with the new version.

Current Behavior

The environment variables on the Lambda configuration was updated, but no new alias/version published.

Reproduction Steps

import * as cdk from 'aws-cdk-lib';
import { Construct } from 'constructs';
import * as lambda from 'aws-cdk-lib/aws-lambda';

export class CdkTestStack extends cdk.Stack {
  constructor(scope: Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    const hello = new cdk.CfnParameter(this, 'HELLO', {
      type: 'String',
    }).valueAsString

    const fn = new lambda.Function(this, 'HelloFunction', {
      runtime: lambda.Runtime.NODEJS_18_X,
      handler: "index.handler",
      code: lambda.Code.fromInline(`
        exports.handler = async function (event) {
          console.log("EVENT", event);
        };
      `),
      environment: {
        HELLO: hello
      },
    });

    fn.addAlias('live')
  }
}

# first
npx cdk deploy --parameters "CdkTest:HELLO=foo"
# second
npx cdk deploy --parameters "CdkTest:HELLO=bar"

The second time the Lambda will be updated with the new environment variable under Lambda configuration.
But there won't be a new alias version published.

Same goes for other tokenized input like SSM parameter instead of CfnParameter.

When changing the value a hard coded environment variable like HELLO: 'foo' it will publish a new version when changing to HELLO: 'bar'.

Possible Solution

This might not be a bug, but since the documentation for addAlias https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_lambda-readme.html#aliases say:

When you change your lambda code or configuration, a new resource will be created.

It's a bit unexpected behaviour when the environment variable is changed and the Lambda is updated but a new version is not created.

Additional Information/Context

There was a similar issue/feature in SAM: aws/serverless-application-model#413

CDK CLI Version

2.84.0 (build f7c792f)

Framework Version

No response

Node.js Version

v18.16.0

OS

MacOS

Language

Typescript

Language Version

Typescript 5.0.4

Other information

No response

[peterwoodworth]

We compute the hash before the token values are known, so I'm not sure there's a way we would be able to fix this without rethinking how this construct works.

[JZechy]

@peterwoodworth @corymhall So there is the problem with my lambda deployment... While the Lambda function itself always updates with the new build tag parameter, the Alias remains unchanged. This seems to be because CDK doesn't account for late-bound values that can fundamentally alter the behavior of the Lambda function.

As a temporary workaround, I've resorted to generating a new GUID within my source code for each stack deployment. However, it would be highly beneficial if CDK could handle this natively.

What's the use case?
We deploy a Lambda function from a Docker image as part of our stack, which gets updated by CodePipeline whenever there's a change in the source code. The CodeBuild project, part of the pipeline, produces not only the Docker image but also a JSON template for the stack. This template includes a parameter containing the build tag.

What are we expecting?
We expect that any change in the build tag should trigger the deployment of a new version of the Lambda Alias. This is crucial for ensuring that the Alias always points to the correct version of the Lambda function.

Closing Thoughts
It's reasonable to expect that any change to the Lambda function, no matter how minor, should trigger an update to its corresponding Alias. The absence of information in the documentation about the hash computation not accounting for tokens only exacerbates the confusion. This is a significant oversight that can affect production systems, and I believe it merits prompt attention.

[Lewenhaupt]

I just realised this and this makes me very worried about our production environments where it will be very difficult if we ever had to change an ssm-parameter. @peterwoodworth