bug: Creating a new VPC and looking up a resource from an SSM Parameter Value forces CDK redeploy even when there are no changes

[Garethp]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

Due to #8222, if you want to use a VPC in your stack you basically have to always use new Vpc(), you can't refer to an existing one. However, when you do that in the same stack that you're also doing something along the lines of Queue.fromArn where the arn is coming from a StringParameter.valueForStringParameter then performing a cdklocal deploy on that stack will always trigger a full update of the stack even when there's no diff.

Expected Behavior

The stack should realize that there are no changes and not perform the full update

How are you starting LocalStack?

With a docker-compose file

Steps To Reproduce

How are you starting localstack (e.g., bin/localstack command, arguments, or docker-compose.yml)

docker run localstack/localstack

Client commands (e.g., AWS SDK code snippet, or sequence of "awslocal" commands)

import { Stack, StackProps } from "aws-cdk-lib";
import { Construct } from "constructs";
import { StringParameter } from "aws-cdk-lib/aws-ssm";
import { Queue } from "aws-cdk-lib/aws-sqs";
import { Vpc } from "aws-cdk-lib/aws-ec2";

export class ProviderStack extends Stack {
  constructor(scope: Construct, id: string, props: StackProps) {
    super(scope, id, props);

    const queue = new Queue(this, "Queue");

    new StringParameter(this, "QueueArn", {
      stringValue: queue.queueArn,
      parameterName: "queue-arn",
    });
  }
}

export class ConsumerStack extends Stack {
  constructor(scope: Construct, id: string, props: StackProps) {
    super(scope, id, props);

    new Vpc(this, "Vpc");

    const queueArn = StringParameter.valueForStringParameter(this, "queue-arn");
    Queue.fromQueueArn(this, "Queue", queueArn);
  }
}

cdklocal deploy provider --require-approval never
cdklocal deploy consumer --require-approval never
cdklocal deploy consumer --require-approval never

Environment

- OS: Ubuntu 20.04
- LocalStack: latest

Anything else?

I've reproduced the issue here: https://github.com/Garethp/localstack-testing/tree/vpc-and-lookup-redeploy
If you clone down the branch vpc-and-lookup-redeploy, run yarn install, and then ./start.sh you should see the issue in action.

I found isolating this bug confusing and trying to wrap my head around why this might occur also confuses me. If you have only one of either the VPC or the Lookup, it works fine and shows that there's nothing to deploy when you attempt to re-deploy it. It's only when you have both. I assume that other combinations can cause full-stack redeployments, but this is just the first one I found when isolating the issue of getting full-stack redeployments when there are no diff

[Garethp]

By throwing some debug logs into template_deployer::resource_config_differs I found that in this test case what appears to be getting detected differences between the ChangeSet and the existing resource are the properties that refer to other resources. For example, a Subnet's VpcId in the existing resource will have a value of vpc-fcc2ffdc (The ID of the VPC) while the ChangeSet will have the value as {'Ref': 'Vpc8378EB38'}, referring to it's Logical ID instead.

I'm not sure how helpful this is, since if you comment out the part about fetching the Queue from SSM then it doesn't even execute a ChangeSet on the second deploy to begin with

[localstack-bot]

Hello 👋! It looks like this issue hasn’t been active in longer than five months. We encourage you to check if this is still an issue in the latest release. In the absence of more information, we will be closing this issue soon. If you find that this is still a problem, please feel free to provide a comment or upvote with a reaction on the initial post to prevent automatic closure. If the issue is already closed, please feel free to open a new one.

[Garethp]

@simonrw, carrying on from our conversation on Wednesday this might issue might be of interest to you. It's an example of stacks being updated even when there's no diff to begin with. I don't know if this is fixed on the latest dev builds, but it's still present on 4.3.

I hope you don't mind the ping, but this seems like a use-case that might not make its way into day-to-day testing.

[simonrw]

It's an example of stacks being updated even when there's no diff to begin with. I don't know if this is fixed on the latest dev builds, but it's still present on 4.3.

I hope you don't mind the ping, but this seems like a use-case that might not make its way into day-to-day testing.

Thanks for the heads up. We are building out a new CFn engine which is more accurate in dispatching update requests. The current engine is too eager as you have noted, and will mark resources for updates even when there is none to be done. The new engine will be more selective.

I'm sorry we did not tackle this original issue. At the time update support for CFn was not a priority for us, but over the year it increased in importance leading to the current rewrite.

I am very excited for this new version, I think having a reliable CFn engine supporting updates will be such a devx boost for those of us who like CFn/CDK!