You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With #97 , we now fill the tfstate with TF ID if it's empty and there is no ongoing operation. However, there are resources, like GCP KMS Keyring, whose deletion doesn't happen immediately. Terraform marks them for scheduled deletion and then removes the object from the tfstate. Since we now fill the id in the next reconcile, it queries the cloud provider and imports the resource whose deletion is scheduled. So, it gets into this loop until the keyring is physically deleted which could take days.
The impact of this bug is limited to only such resources.
What happened?
With #97 , we now fill the tfstate with TF ID if it's empty and there is no ongoing operation. However, there are resources, like GCP KMS Keyring, whose deletion doesn't happen immediately. Terraform marks them for scheduled deletion and then removes the object from the tfstate. Since we now fill the id in the next reconcile, it queries the cloud provider and imports the resource whose deletion is scheduled. So, it gets into this loop until the keyring is physically deleted which could take days.
The impact of this bug is limited to only such resources.
How can we reproduce it?
This is the failed Uptest run https://github.com/upbound/official-providers/actions/runs/3128437565
You can run the following command locally after preparing
ProviderConfig
of GCP:The text was updated successfully, but these errors were encountered: