Source of Providers might caused an (Error: Provider configuration not present)

I had a null_resource that I deleted and now terraform plan is failing because of the provider doesn’t exist anymore. The provider is needed in the configuration to allow terraform to clean up the resource.

So in order to solve the issue I added the following to main.tf

terraform {
  required_providers {
    archive = "~> 1.3.0"
    null = "~> 2.1.2"
  }
}

However when I run terraform plan again it fails with

Error: Provider configuration not present

To work with null_resource.build_deps its original provider configuration at
provider["registry.terraform.io/-/null"] is required, but it has been removed.
This occurs when a provider configuration is removed while objects created by
that provider still exist in the state. Re-add the provider configuration to
destroy null_resource.build_deps, after which you can remove the provider
configuration again.

So I run terraform providers and I got the following

Providers required by configuration:
.
├── provider[registry.terraform.io/hashicorp/archive] ~> 1.3.0
├── provider[registry.terraform.io/hashicorp/null] ~> 2.1.2
└── provider[registry.terraform.io/hashicorp/aws] ~> 2.0

Providers required by state:

    provider[registry.terraform.io/-/archive]

    provider[registry.terraform.io/-/aws]

    provider[registry.terraform.io/-/null]

Question
By looking at list of providers (required by configs vs required by state) you can see a slight difference in the source path. One is pulling the provider from HashiCorp in the path while the state providers has (-) in the path.

Any idea if this is what causing the problem? If so How can I fix it? Declaring providers differently maybe?

Hi @mixeract,

From this output it seems that you have a half-completed migration to Terraform 0.13, where you’ve updated the configuration to include the new provider requirements but the second step (of updating the state to match) has been blocked because something else has changed in your configuration at the same time and Terraform doesn’t know how to proceed.

One way to proceed here would be to explicitly make the state changes that Terraform would normally make automatically the first time you run terraform apply after adding the new provider_requirements specifications. You can run the following commands to explicitly update the legacy provider addresses in the state to match the new addresses in the configuration:

terraform state replace-provider 'registry.terraform.io/-/null' 'registry.terraform.io/hashicorp/null'
terraform state replace-provider 'registry.terraform.io/-/archive' 'registry.terraform.io/hashicorp/archive'
terraform state replace-provider 'registry.terraform.io/-/aws' 'registry.terraform.io/hashicorp/aws'

Note that each of these commands will create a new state snapshot in your configured backend, and that new snapshot will be in Terraform 0.13 format and so the state will then no longer be compatible with Terraform 0.12.

After these commands succeed, you should be able to run terraform providers and see that the “Providers required by state” now match the ones required by the configuration. Then terraform apply should be able to match this null_resource.build_deps resource with the configured null provider and successfully produce the plan to destroy null_resource.build_deps.