aws-lambda: version incorrectly created when function property changes but value stays the same

[jonkipu]

Describe the bug

This case is a bit convoluted but it happened to me multiple times, this is only my assumption of what's happening.

For a given function:

const fn = new NodejsFunction(this, "Func", {
    environment: {
        TEST: Fn.importValue("ValueFromOtherStack")
    }
});
fn.addAlias("live");

When deployed a version will be correctly created, now assuming "ValueFromOtherStack" is exported as the string "test", if we change the deployment code to be:

const fn = new NodejsFunction(this, "Func", {
    environment: {
        TEST: "test"
    }
});
fn.addAlias("live");

Without changing the function code, could be for the sake of changing the exported value (since you can't change export if they are already in use), the internal logic of Version will recalculate the logical id (this is my assumption) since the properties changed, yet when deploying to CF, CF will see the function's configuration to be the same and refuse to create a new version resulting in the following error:
Version already exists: [...]. Please modify the function to create a new version.

Expected Behavior

Not sure, either creating a new version or not is fine by me but this fails deployment and happens quite frequently for me

Current Behavior

Deployment fails and an artificial change has to be done to one of the function's properties.
If this was one function that would be one thing, but this happens for me on multiple occasions for multiple functions

Reproduction Steps

Deploy function with the first code example
Attempt to deploy function with the second code example without changing any other property or function code and see the deployment fail

Possible Solution

Not sure how can this be solved since CDK is right to assume the logical id changes here since the property changed, but it cannot see the values are the same due to them being deploy time variables

Additional Information/Context

No response

CDK CLI Version

2.102.0

Framework Version

No response

Node.js Version

any

OS

any

Language

TypeScript

Language Version

No response

Other information

No response

[pahud]

Have you run cdk diff and see the result?

In my case, the old version resource will be destroyed with a new version with new logicalId being created and the alias will in-place updated and point to the new version.

I can successfully deploy the update with no error.

cdk 2.106.0

[github-actions]

This issue has not received a response in a while. If you want to keep this issue open, please leave a comment below and auto-close will be canceled.

[jonkipu]

Sorry for the late response!
Just ran it again and my diff was similar to yours (environment variable change and a change in the Lambda::Alias FunctionVersion prop), yet the deployment failed with the same error.
Can you try it the other way around (from literal value to imported value)?

[mrgrain]

I suspect this is because "test" (the string) and Fn.importValue("ValueFromOtherStack") (an object) are different values on the client side where the hash is calculated. However in CFN (or more specific the call to the respective Lambda API) they end up being the same. Not super sure how to solve this. FWIW I think you can also change the description, no need to change the code.

[jonkipu]

That was my suspicion as well (although it doesn't seem to reproduce for @pahud)
While I understand that changing any prop (such as the description) will resolve this, it is still an inconvenience to either remember doing so or even wanting to.
Since when changing imported values from other stacks I'll need a similar change (since I can't change exports in use) this can happen a lot (I have a lot of stacks), remembering to make an artificial change isn't something I want to rely on.

This also happened to me and my team where seemingly innocuous changes such as this were made and merged only to be discovered as breaking deployments at a later stage

Also not sure how this can be resolved if it is indeed the issue

[mrgrain]

(although it doesn't seem to reproduce for @pahud)

Yes, that's odd.

We have an Aspect that is/was used to mitigate an issues that was resolved by a feature flag. tl;dr It auto updates the description with the calculated hash. Maybe you can adopt a similar pattern.

[enpatrik]

Looks like you experienced the same/similar issue as I reported here: #25997