terraform: catch scenario where both "foo" and "foo.0" are in state

[mitchellh]

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 and type.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 assume type.name is the valid resource to use, and the type.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 and count = 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:

• In the PruneDestroyTransform, we must not prune the destroy node if we see this scenario.
• In the 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:

• 0.3.7 and before: the 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.
• master prior to this patch: the type.name.0 value is always used, and type.name is completely ignored. The inverse of 0.3.7 and before. But likewise, type.name is therefore never fixable.
• master after this patch: type.name.0 is treated as an orphan, type.name is used. We chose this route because 0.3.7 use type.name so we should use those values for BC reasons.

[mitchellh]

Removed this since we weren't using it in the test.

[pmoust]

thanks @mitchellh, trying this out now

[pmoust]

@mitchellh orphan nodes do get removed from state, however some dependent entities (i.e. aws_route53_records) that double-existed in state, are marked for deletion in plan. I suppose because they were linked to .0 type.

Another question, if an entity supporting count is set as count=1, will this generate a .0 or it will have no index? If its the latter, is the case of count=X (X>1) and after a while decreased to 1 handled? Will dependent resources of the first entity be preserved or will those that had been linked to .0 and be marked for deletion?

I hope I've understood the PR correctly and making a bit of sense. Still early here, on my first coffee still.

[mitchellh]

@pmoust count=1 will put it in the state without the zero suffix, now. But it doesn't matter because when referencing a resource with type.name.0.attribute, both will be checked (first state matching will be used).

The case of increasing/decreasing counts is very heavily tested. (From no count, to X count, to 1 count, to X-prime, etc.).

In your case, the aws_route53_record was marked for deletion because you had two of those as well. I'll respond in your private repo why you saw what you did.

[pmoust]

@mitchellh thanks for the quick action on the patch and the walkthrough, man!

[mitchellh]

No problem, thanks for the great bug reports. :)

[ghost]

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.