fix(efs): support imported subnet

[phuhung273]

Issue # (if applicable)

Closes #33876

Description of changes

LogicalId generation cover unresolved token case.

Description of how you validated changes

Unit + Integ

Checklist

• My code adheres to the CONTRIBUTING GUIDE and DESIGN GUIDELINES

---

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

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 83.98%. Comparing base (242091a) to head (3290166).
Report is 16 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main   #34041   +/-   ##
=======================================
  Coverage   83.98%   83.98%           
=======================================
  Files         120      120           
  Lines        6976     6976           
  Branches     1178     1178           
=======================================
  Hits         5859     5859           
  Misses       1005     1005           
  Partials      112      112           

Flag	Coverage Δ
suite.unit	83.98% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Components	Coverage Δ
packages/aws-cdk	∅ <ø> (∅)
packages/aws-cdk-lib/core	83.98% <ø> (ø)

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[shikha372]

Can’t we handle this specifically for unresolved token values? For example, we could check if subnet.node.id is an unresolved token — if it is, we replace it with a unique ID; otherwise, we leave it as is. From what I see, the current implementation likely doesn't work correctly when the value is unresolved. This check should allow us to conditionally update the value. Let me know if you can think of any scenarios where it would work with token values — in that case, we might need to introduce a feature flag.

[phuhung273]

Thank you for your guidance, i should have done that in the 1st place. This logic is updated as suggested, please have a check.

[shikha372]

Thank you @phuhung273 , looking at this again, i can think of one more use case for this scenario, where you're referring to the subnet ID of an existing VPC and not an imported subnet, something like

const vpc = new ec2.Vpc(stack, 'Vpc', {
  natGateways: 1,
  restrictDefaultSecurityGroup: false,
  subnetConfiguration: [
    {
      name: 'test',
      subnetType: ec2.SubnetType.PUBLIC,
    },
  ],
});

const fileSystem = new FileSystem(stack, 'FileSystem', {
  vpc,
  vpcSubnets: vpc.selectSubnets({
    subnets: vpc.publicSubnets,
  }),
});

can we confirm it doesn't impact the existing subnet references that are created through CDK, want to make sure that we don't change this mistakenly for any case of non-imported subnets before opting out of feature flag.

[phuhung273]

Sorry this took a while as I had no idea how to validate all cases, but here are what I found:

For the case that you're referring to

Can confirm that subnet.node.id is not a token, therefore still keep old logic.

Checking ec2.Vpc constructor

All subnets created by constructor are given a non-token id, following pattern Subnet1, Subnet2, Subnet3, matching with the behaviour of above case

aws-cdk/packages/aws-cdk-lib/aws-ec2/lib/vpc.ts

Line 1761 in 7f378b6

subnetConstructId: subnetId(configuration.name, index),

aws-cdk/packages/aws-cdk-lib/aws-ec2/lib/util.ts

Lines 42 to 44 in 7f378b6

	export function subnetId(name: string, i: number) {
	return `${name}Subnet${i + 1}`;
	}

Most important point

If there is any case that we haven't covered, and it is a token, then it doesn't even work from the first place, yelling the same error as the originated issue.

Your amazing suggestion to use Token.isUnresolved ensures we only cover those cases that never work. I think it's totally safe. Let me know if you can think of any other cases.

[shikha372]

Awesome, thank you @phuhung273

[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: e669292
• 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).

[github-actions]

Comments on closed issues and PRs are hard for our team to see.
If you need help, please open a new issue that references this one.