terraform: catch scenario where both "foo" and "foo.0" are in state #1086
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #1047 (cc @pmoust)
I'm not sure what caused this, but it seems that there is a possibility in the state to have both a
type.name
andtype.name.0
to be present. If both of these are present, we experience some very bizarre behavior. In 0.3.7 and prior, it appears we just assumetype.name
is the valid resource to use, and thetype.name.0
value is completely ignored. There seems to be no way to do anything with it (including remove it) short of modifying the state.This PR causes the
type.name.0
to behave as an orphan in the case both are present andcount = 1
. While in theory it is possible that either are the one you want, I think in practice we should remove the.0
resource because it appears that this is how 0.3.7 behaved by completely ignoring it (therefore not destroying it but also not using its values for any dependent resources).The fix here is pretty simple:
PruneDestroyTransform
, we must not prune the destroy node if we see this scenario.FixZeroOneBoundary
eval node, we must not override and therefore mask the value if we see that both the hunt and replace exist. This will cause both to remain and the orphan transform to pick it up later.I don't think its possible going currently in master and going forward to ever persist a state with both, so this situation must be a backwards compat possibility.
To be clear, here is the before/after:
type.name.0
value is always completely ignored. It is not treated as an orphan, attributes are not reference-able, it is in the state but never affects plans/applies in any way. It is as if it isn't there.type.name.0
value is always used, andtype.name
is completely ignored. The inverse of 0.3.7 and before. But likewise,type.name
is therefore never fixable.type.name.0
is treated as an orphan,type.name
is used. We chose this route because 0.3.7 usetype.name
so we should use those values for BC reasons.