feat(cli): support hotswapping Lambda function's description and environment variables

[huyphan]

This change allows Lambda function to be hotswap'ed when there's change in the function's description and/or environment variables. These changes are categorized as configuration changes and are updated by calling updateFunctionConfiguration. Since the existing waiter "UpdateFunctionCodeToFinish" is now used to wait for both code update and configuration update, I renamed it to "UpdateFunctionPropertiesToFinish".

resolves #20787

---

All Submissions:

• Have you followed the guidelines in our Contributing guide?

Adding new Unconventional Dependencies:

• This PR adds new unconventional dependencies following the process described here

New Features

• Have you added the new feature to an integration test?
  • Did you use yarn integ to deploy the infrastructure and generate the snapshot (i.e. yarn integ without --dry-run)?

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

[gitpod-io]

[rix0rrr]

The goal of this feature is not to reimplement CloudFormation, but faster. It's to increase speed on common development tasks, such as iterating on runtime code.

What is the use case for changing these values so often that it becomes a productivity killer to have to wait 30s instead of 1s when you do?

[huyphan]

The issue #20787 has more context there. But to summarize:

The goal of hotswap feature is not to reimplement CloudFormation, but faster.

The purpose behind this change is not to implement more CloudFormation's behaviour. This change is not even about improving the speed of updating Lambda function's description or environment variables. It's about unblocking hotswap when those fields are updated.

Why those fields need to be updated regularly? What is the use case?

It's one of the workarounds to get Lambda version to work with S3 code provider (see CDK's note about it).

Why can't we use the other workarounds, such as defining a dynamic Lambda::Version object?

This does allow hotswap to work, but will fail subsequent full deployments. See more in #20787.

--

Update: rephrase the summary to make the purpose of this change clearer.

[comcalvi]

In (3), the error you get is:

Modify the function to create a new version.

For subsequent deployments, can you make a trivial change to the function's description to get around this CFN error? I do not think that the complexity added to the lambda hotswap logic is worth it.

[huyphan]

I can do it. But I don't think it's a right customer experience if we ask every one to do it:

1. When the failure happens, the presented error message is about Lambda version conflict and does not explain exactly what users have to do to resolve it (source: I work for a team that helps other developers to build Lambda applications and many new developers did not know how to workaround this issue).
2. Making changes to the Lambda function and rebuilding it every time you update your infrastructure package is not trivial. Large lambda code base takes time to build, and users can easily forget to do this step at times.

[rix0rrr]

It's one of the workarounds to get Lambda version to work with S3 code provider

Ahh, I see. Would have helped if you had made the motivation more clear in the PR body :).

[mergify]

Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).

[aws-cdk-automation]

AWS CodeBuild CI Report

• CodeBuild project: AutoBuildv2Project1C6BFA3F-wQm2hXv2jqQv
• Commit ID: e64df8e
• Result: SUCCEEDED
• Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

[mergify]

Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).

[mrgrain]

@huyphan This is failing the CLI integration tests in cli.integtest.ts
Unfortunately they are not run on the PR build, so you'll have to check them locally.

[huyphan]

@mrgrain is there any chance I can have access to the full test log? The test case that you linked to (ci=true -> output to stdout) does not fail on my local environment, but another test failed instead (generating and loading assembly).

I will update the PR to address the generating and loading assembly test case, but it's a bit tricky to address the first one since I can't reproduce it yet.

[mrgrain]

@huyphan My bad! I had linked you to the wrong test case. generating and loading assembly is the only one failing. I will provide the log next time, that's a good call out. Unfortunately it's a manual thing to get and post it.

[huyphan]

Thank you! Since this PR is closed, I made another PR with the same change and the fix for the failed integration test case: #21532