No longer accessing another stack's resource causes deadly embrace

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

[austinbv]

Our solution is to deploy the substack with the -e flag then deploy the parent stack.

Even some documentation around that would be stronger than just two immutable stacks. Could you always update leaf nodes first, then update the full stack again

[skinny85]

@Dzhuneyt while dealing with removing cross-stack references can be tricky in the CDK, there is actually a way to do it. Check out this article: https://www.endoflineblog.com/cdk-tips-03-how-to-unblock-cross-stack-references for a step-by-step guide on how to unblock yourself.

Thanks, Adam