-
Notifications
You must be signed in to change notification settings - Fork 3.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
aws-lambda: Logical id of current version changes when upgrading form v2.87.0 to v2.88.0 #26739
Labels
@aws-cdk/aws-lambda
Related to AWS Lambda
bug
This issue is a bug.
effort/medium
Medium work item – several days of effort
p0
Comments
rehos
added
bug
This issue is a bug.
needs-triage
This issue or PR still needs to be triaged.
labels
Aug 12, 2023
rehos
changed the title
aws-ambda: Logical id of current version changes when upgrading form v2.87.0 to v2.88.0
aws-lambda: Logical id of current version changes when upgrading form v2.87.0 to v2.88.0
Aug 14, 2023
pahud
added
p0
effort/medium
Medium work item – several days of effort
and removed
needs-triage
This issue or PR still needs to be triaged.
labels
Aug 14, 2023
Yes I can reproduce this. The Logical Id should not change. |
rix0rrr
added a commit
that referenced
this issue
Aug 16, 2023
Between version `2.87.0` and version `2.88.0`, the hash calculation used to make sure that `fn.currentVersion` is automatically updated when a new version of the Lambda Function is deployed changed. This causes a creation of a new Version upon upgrading CDK, but that new Version creation will fail because the underlying Function hasn't changed. The change was due to property ordering used in calculating a unique hash for the Function configuration. This change restores the property ordering to the pre-2.88.0 behavior. Fixes #26739.
mergify bot
pushed a commit
that referenced
this issue
Aug 17, 2023
…26777) Between version `2.87.0` and version `2.88.0`, the hash calculation used to make sure that `fn.currentVersion` is automatically updated when a new version of the Lambda Function is deployed changed. This causes a creation of a new Version upon upgrading CDK, but that new Version creation will fail because the underlying Function hasn't changed. The change was due to property ordering used in calculating a unique hash for the Function configuration. This change restores the property ordering to the pre-2.88.0 behavior. Fixes #26739. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
@aws-cdk/aws-lambda
Related to AWS Lambda
bug
This issue is a bug.
effort/medium
Medium work item – several days of effort
p0
Describe the bug
I wanted to upgrade the CDK from 2.87.0 to 2.91.0 but ran into a deployment failure:
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:
npm install
npm run cdk synth
cdk.out/MyStack.template.json
and notice the logical id of the lambda version isMyLambdaCurrentVersionE7A382CC40566d291e26de5fbeddf64c72bb9661
package.json
and change the version of bothaws-cdk
andaws-cdk-lib
to2.88.0
npm install
npm run cdk synth
cdk.out/MyStack.template.json
and notice the logical id of the lambda version is changed toMyLambdaCurrentVersionE7A382CC6466d36c9d15346e31eee2175be4ea3e
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.
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 forAWS::Lambda::LayerVersion
in a different order than v2.88.0.and
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
The text was updated successfully, but these errors were encountered: