Skip to content

No longer accessing another stack's resource causes deadly embrace #7602

@mcalello

Description

@mcalello

CDK's automatic determination and synthesis of exports to imports can get locked into a deadly embrace that cannot be resolved without destroying your stacks.

Reproduction Steps

Stack1 creates a common Security Group, sg1.
Stack2 uses sg1.

CDK's automatic determination and synthesis described here, will generate an export output from Stack1 for sg1 and an Fn:ImportValue into Stack2.

Then you deploy these stacks.

Later, you decide that Stack2 really needs it's own more specific Security Group, so you create it's own sg2. Again, CDK's automatic determination and synthesis realizes that sg1 is no longer referenced by Stack2 (or any other stack) and attempts to delete the Export of sg1 from Stack1.

This will fail and cannot be deployed.

CloudFormation will be prevented from deleting sg1 as an export from Stack1 since it is currently being used as an Import in the (existing) Stack2. Ironically, you were trying to update Stack2 to no longer reference Stack1's sg1.

Error Log

UPDATE_ROLLBACK_IN_P | AWS::CloudFormation::Stack  | Stack1 Export Stack1:ExportsOutputFnGetAtt-sg1-C785ABD5GroupId30372C66 cannot be deleted as it is in use by Stack2

Environment

  • **CLI Version : aws-cli/1.16.223 Python/3.7.4 Darwin/18.7.0 botocore/1.12.213
  • **Framework Version: 1.34.1 (build 7b21aa0)
  • **OS : macOS 10.14.6
  • **Language : Python3

Other


This is 🐛 Bug Report

Metadata

Metadata

Assignees

Labels

bugThis issue is a bug.cross-stackRelated to cross-stack resource sharingeffort/mediumMedium work item – several days of effortp1

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions