-
Notifications
You must be signed in to change notification settings - Fork 4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
NestedStack parent resource reference generates Circular Dependency #5888
Comments
@eladb Based on the history you are most related to NestedStack, maybe you can have a quick look over it? I have debugged it:
In the above stack structure and it falls under the 1st condition from inside. Even if stacks are siblings it still doesn't work even though there is no Circular Dependency validation error in that case. The deploy just fails. |
@xoadrian - thanks for reporting. I'll take a look later today and run through your reproduction steps |
#7187) Fixes #6473 by centralizing all the logic to resolve cross-references into `App.prepare()`. This allows reasoning about the entire application once from a single code flow, dramatically simplified the algorithm and solved the issue at hand (and probably a handful of other issues). This logic is implemented in a function called `prepareApp` which is normally called from `App.prepare()` but if a `Stack` is created as a root (normally in unit tests, we invoke this logic from there to retain current behavior). This algorithm takes care of both resolving cross references and add template assets for nested stacks. This is because assets are currently addressed using CFN parameters, which means that when we adding them to the parent of a nested stack, the parent is mutated, so we need to rectify references again. To make sure this is done correctly, we always create assets in DFS order. Fixes #7059 Fixes #5888
#7187) Fixes #6473 by centralizing the logic to resolve cross-references and prepare nested stack template assets in `App.prepare`, which has a global view of the app and is the last prepare to execute before synthesis. This dramatically simplified reference resolution and allows dealing with nested stack assets only after all cross references have been resolved (the root cause for #7059). This logic is implemented in a function called `prepareApp` which is normally called from `App.prepare()` but if a `Stack` is created as a root (normally in unit tests, we invoke this logic from there to retain current behavior). This algorithm takes care of both resolving cross references and add template assets for nested stacks. This is because assets are currently addressed using CFN parameters, which means that when we adding them to the parent of a nested stack, the parent is mutated, so we need to rectify references again. To make sure this is done correctly, we always create assets in DFS order. All changes to the test snapshots stem from new asset IDs of nested stack templates, not the template themselves. The change is a result of the fact that the refactor caused the "Parameters" section to appear in a different place in the template, but the template itself is identical. Fixes #7059 by first resolving all references in the app and only then calculating the hash of the nested stack templates for their assets. Fixes #5888 but this was not verified.
I have the following stack structure:
In
AppSync(NestedStack)
I am creating API, schema and instantiating nested stack for Resolvers, main reason for this this that there are many resolvers and to not hit 200 Resrouce limit I will be manually splitting resources between multiple Resolvers nested stack. Currently I don't know an automated way for splitting resources, if there is please, please share :).I also tried changing the structure to have nested stacks as siblings, which get's rid of Circular dependency but then it just fails on deploy:
Reproduction Steps
cdk.ts:
root-stack.ts:
appsync-stack.ts
resolvers-stack:
Error Log
CFN template generates reference to itself(root-stack.template):
appsync-stack.template:
resolvers-stack.template:
Environment
Other
This is 🐛 Bug Report
The text was updated successfully, but these errors were encountered: