-
Notifications
You must be signed in to change notification settings - Fork 9.6k
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
Spurious "UpgradeResourceState" call during "destroy" workflow #30460
Comments
Hi @alexsomesan, What you're seeing here is is part of the destroy plan process, but I think because planning destroy operations were previously only done internally, the providers never needed to be configured at that point. I'm reviewing the possibility of including the providers in the process of planning individual destroy operations already and I should be able to add the configuration call there too. Thanks! |
Hi James! Thanks for the explanation. I was mostly confused by the fact that the destroy process already does a planning phase with all the usual ConfigureProvider -> UpgradeResourceState -> PlanResourceChange right before the call in question here (see logs above). Given all this, is the intermediate call to UpgradeResourceState really intentional and serving a specific purpose? On a side note, I was able to unblock myself by adding a check for valid provider configuration in my UpgradeResourceState and cutting it short when config is missing. However, I'd rather not keep that in there long term as it might lead to some false positives in corner cases that aren't apparent to me now. |
The two separate calls you see during destroy are because we first need to do a full plan to get the refresh information, mostly for data sources which may be referenced by the providers themselves, but it will also clean out any missing resources early on. The second call is during the actual destroy plan. We never previously called the provider to plan anything because all changes are delete changes, hence we never configured the provider, but we do need to fetch the state data again which in turn calls the I'm not sure yet how a new proposed destroy plan will look exactly, but we may be able to combine these operations into a single plan. Regardless, if we do add the |
I think regardless of whether we call |
Just to update for v1.2 -- The current destroy graph implementation was written to be a completely offline operation, with no input from the provider (other than fetching schemas of course), so there is not enough information at the moment to configure the provider at all. This means fixing the missing config turns out to be a bit more involved than just calling |
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. |
Terraform Version
Terraform Configuration Files
# any configuration
Debug Output
Apply
Destroy
Expected Behavior
UpgradeResourceState
should not be called beforeConfigureProvider
Actual Behavior
During a
destroy
workflow, a new provider process is spawed between theplan
andapply
stages onto which a singleUpgradeResourceState
call is made without any precedingConfigureProvider
calls.If the state upgrade logic makes use of any values from the provider block, the whole
destroy
workflow will fail.Steps to Reproduce
UpgradeResourceState
that tries to use values from the provider block.terraform apply
to produce some state.terraform destroy
Additional Context
References
The text was updated successfully, but these errors were encountered: