-
Notifications
You must be signed in to change notification settings - Fork 9.7k
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
always check the CreateBeforeDestroy value from state #26263
Conversation
When there is only a destroy node, there is no descendent to check for "forced CBD", so we can only rely on the state to verify.
Correct the initial test state, and expand the test to cause a cycle without the previous fix.
Codecov Report
|
func (n *NodeApplyableResourceInstance) AttachDestroyNode(d GraphNodeDestroyerCBD) { | ||
n.destroyNode = d | ||
} | ||
|
||
// CreateBeforeDestroy checks this nodes config status and the status af any |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this comment is out of date now? It's no longer checking the companion destroy node?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks reasonable to me (admittedly based more off your tests and explanation)! I left one tiny question about a comment; its not a blocker.
Remove the check for CreateBeforeDestroyOverride which can't happen in a destroy node. Remove the unnecessary GraphNodeAttachDestroyer interface, since we don't use it now that plans can record the create+destroy order.
a250b05
to
a6dffa8
Compare
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further. |
When destroying an instance which was forced to be
CreateBeforeDestroy
from downstream consumers, we were inadvertently preferring the config value over the state value forCreateBeforeDestroy
. TheCreateBeforeDestroyOverride
was not useful in this case, because a destroy node does not have the same descendants as the plan node, and we cannot check for a forcedCreateBeforeDestroy
in the same manner, so we need to trust the value from state.The last commit is extra cleanup of some unnecessary interfaces, and is not going to be part of the backport candidate.
This fixes the cycle in #26226, and converts it into a duplicate of #25631.