backend/local: don't panic when an instance has only a deposed object #21575
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.
This unusual situation isn't supposed to arise in normal use, but it can come up in practice in some edge-case scenarios where Terraform fails in a severe way during a
create_before_destroy
.Some earlier versions of Terraform also had bugs in their handling of deposed objects, so this may also arise if upgrading from one of those older versions with some leftover deposed objects in the state.
This fixes #21396.
Some additional context:
In working on this I noticed that in principle the specific situation I covered in the test here could be simplified to just a normal
create_before_destroy
in the UI, because that is effectively what's going to happen anyway.However, the UI handling of deposed instances is generalized to deal with a bunch of other similar edge-cases around deposed instances. The main one it's dealing with is the situation where the "destroy" part of a
create_before_destroy
fails and thus the state ends up containing both a current instance and a deposed instance at the same time. If the user then updates the config again and triggers anothercreate_before_destroy
then the destroy can fail again and accumulate two deposed instances, like this:The above situation is also rare, but it's less rare (easier to run into) than the one this fix is aimed at, and so that's why the UI treatment of deposed objects is designed around this latter case (where combining into a single action isn't possible) rather than the "deposed only" situation (where it could potentially be).