Open enpatrik opened 1 year ago
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.
@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.
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
Ran into this with AWS Batch, passing the job definition ARN (that has a version) into a Lambda environment variable.
Now I'm worried what else is miswired. Large deployment, many, many stacks and resources.
probably related to https://github.com/aws/aws-cdk/pull/30093
The issue is still there in the latest (v2.143.0) version.
Pushed a repo with the reproduction scenario: https://github.com/enpatrik/cdk-issue-25997
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
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 toHELLO: '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:
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: https://github.com/aws/serverless-application-model/issues/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