Looking up an unknown VPC yields false Id (DUMMY_VPC_PROPS vpc-12345)

[hlascelles]

When using fromLookup for a VPC that is not known no error is thrown and a false Id is returned (vpc-12345).

Reproduction Steps

To demonstrate:

    logger.info("Looking for VPC...");
    const vpc = Vpc.fromLookup(this, "Vpc", {vpcName: "foo"});
    logger.info("Found VPC " + vpc.vpcId);

Logs:

info: Looking for VPC...
info: Found VPC vpc-12345

The env is being passed in with account and region.

vpc-12345 is the real value that is always returned. It is not an example in the code above.
This is unexpected, especially if the VPC cannot be found. Should an error should be thrown or null returned if the VPC cannot be found?

I see in the code this is the DUMMY_VPC_PROPS. Surely this should only be returned in tests?

NB Other VPC lookups succeed. This bug report is that a dummy VPC should not be returned if it does not find the VPC.

Environment

• CLI Version : 1.30.0 (build 4f54ff7)
• Framework Version: 1.32.2
• OS : Any
• Language : Typescript

There is nothing in the context that would cause this.

---

This is 🐛 Bug Report

[hlascelles]

I am becoming more certain this has to do with the CDK phases. However, this dummy value seems to be returned always, not just in the first phase. I can see there is a missing in the manifest.json.

I will do some more reading up and reopen if I can give a clear question on how this kind of thing should be handled.

[hlascelles]

I have more of a grip on it now. For anyone following this issue, I solved it by running cdk list repeatedly with each set of AWS account credentials to populate the cdk.context.json file with the VPCs snapshots. I also had to modify the code to cater for the fact that the dummy VPC has no isolatedSubnets. The code I was using was in an aws example and needs to be changed thus if you are passing in existing subnets.

    if (vpc.isolatedSubnets.length > 0){
      // Do something
    }

Each time it ran it saved one more VPC config to file and then errored as the unknown VPCs were the DUMMY ones. However, it got further and further each time until cdk.context.json was fully populated.

I suppose in summary this issue was "the DUMMY vpc which is used by cdk in the first run 'phase' has no isolatedSubnets, but the real VPCs that I was expecting it to find always do". I can see now why this is a very hard problem for CDK to solve!