aws-cdk-lib/aws-lambda: Incorrect order of operations when changing both Python version and architecture

[cmenning]

Describe the bug

When changing both Python runtime version and architecture, the order of operations prevents the operation from succeeding. For example, if a deployed Lambda is configured for Python 3.9 and ARM64, changing to to Python 3.7 and X86_64 fails during deploy.

Expected Behavior

Changing the runtime and architecture should succeed when deploying.

Current Behavior

During cdk deploy, the Lambda function update fails with the following error message:

ExampleStack | 0/3 | 4:44:26 PM | UPDATE_FAILED | AWS::Lambda::Function | MyFunction (MyFunction3BAA72D1) Resource handler returned message: "Runtime python3.7 does not support the following architectures [arm64]. Please select different architectures from [x86_64] or select a different runtime. (Service: Lambda, Status Code: 400, Request ID: example5-9228-4208-b024-0dd9e9a9b03a)" (RequestToken: example1-f7ef-5669-2ab1-5ed0b6c59b30, HandlerErrorCode: InvalidRequest)

Reproduction Steps

Given the following already-deployed code:

import * as lambda from 'aws-cdk-lib/aws-lambda';

const myFunction = new lambda.Function(this, 'MyFunction', {
    ...
    runtime: lambda.Runtime.PYTHON_3_9,
    architecture: lambda.Architecture.ARM64,
    ...
}

Change the runtime and architecture configuration as follows:

    runtime: lambda.Runtime.PYTHON_3_7,
    architecture: lambda.Architecture.X86_64,

Running cdk diff at this point will show that both runtime and architecture will be updated. Performing cdk deploy causes an error because the runtime is changed before the architecture, and the 3.7 runtime does not support ARM64.

Possible Solution

Change the order of operations to update the architecture before the runtime.

Additional Information/Context

No response

CDK CLI Version

2.92.0 (build bf62e55)

Framework Version

No response

Node.js Version

v18.17.1

OS

Windows 10

Language

Typescript

Language Version

No response

Other information

No response

[peterwoodworth]

Interesting, I was able to reproduce this, thanks for reporting. Unfortunately this is definitely a service bug, so we can't do anything about it. But at the least, I'll report it internally P97355380. You should also create an issue on the CloudFormation coverage roadmap