Provider produced inconsistent result after apply - bug in the provider, which should be reported

[eliassal]

Terraform CLI and Provider Versions

TF version = "~> 3.0"
Provider lat version

Terraform Configuration

terraform {
  required_version = ">= 1.2.1"

  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~> 3.0"
    }

  }
}

Expected Behavior

Added triggers to resource "null_resource" in order that creating image in acr happens when I change some elements in the main.tf such as RG location or subnet adress space.

Actual Behavior

I am working with azure, I added the following block to main.tf (after creating needed resources RG, acr......)

resource "null_resource" "image" {
  triggers = {
    prod = azurerm_container_registry.acr-prod.id
    dev  = azurerm_container_registry.acr-dev.id
  }

  provisioner "local-exec" {
    command     = <<EOT
       
       az acr import --name ${azurerm_container_registry.acr-prod.name} --resource-group ${azurerm_resource_group.rg.name} --source docker.io/library/hello-world:latest --image hello-world:latest
       az acr import --name ${azurerm_container_registry.acr-dev.name}  --resource-group ${azurerm_resource_group.rg.name} --source docker.io/library/hello-world:latest --image hello-world:latest
   EOT
    interpreter = ["pwsh", "-Command"]
  }
}

When I changed the location of the resource group and redid terraform apply I got this error

azurerm_container_registry.acr-prod: Still creating... [10s elapsed]
azurerm_container_registry.acr-dev: Still creating... [10s elapsed]
2023-12-08T11:50:46.812+0100 [ERROR] provider.terraform-provider-azurerm_v3.83.0_x5.exe: Response contains error diagnostic: diagnostic_detail="" diagnostic_severity=ERROR tf_req_id=2b7ab797-16a7-82d2-4b74-f11cc8a8c19a @module=sdk.proto tf_rpc=ApplyResourceChange
diagnostic_summary=
| creating Registry (Subscription: "XXXXXXX-XXXX-460d-8e3b-XXXXXXX"
| Resource Group Name: "rg-acrdemo"
| Registry Name: "acrprodregistrysieraclab001"): polling after Create: unexpected status 404 with error: ResourceNotFound: The Resource 'Microsoft.ContainerRegistry/registries/acrprodregistrysieraclab001' under resource group 'rg-acrdemo' was not found. For more details please go to https://aka.ms/ARMResourceNotFoundFix
@caller=github.com/hashicorp/[email protected]/tfprotov5/internal/diag/diagnostics.go:58 tf_proto_version=5.4 tf_provider_addr=provider tf_resource_type=azurerm_container_registry timestamp="2023-12-08T11:50:46.812+0100"
2023-12-08T11:50:46.849+0100 [ERROR] vertex "azurerm_container_registry.acr-prod" error: creating Registry (Subscription: "f151ee3f-4725-460d-8e3b-82512dfda843"
Resource Group Name: "rg-acrdemo"
Registry Name: "acrprodregistrysieraclab001"): polling after Create: unexpected status 404 with error: ResourceNotFound: The Resource 'Microsoft.ContainerRegistry/registries/acrprodregistrysieraclab001' under resource group 'rg-acrdemo' was not found. For more details please go to https://aka.ms/ARMResourceNotFoundFix
2023-12-08T11:50:47.365+0100 [ERROR] vertex "azurerm_container_registry.acr-dev" error: Provider produced inconsistent result after apply
╷
│ Error: Provider produced inconsistent result after apply
│
│ When applying changes to azurerm_container_registry.acr-dev, provider "provider["registry.terraform.io/hashicorp/azurerm"]" produced an unexpected new value: Root object was present,
│ but now absent.
│
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.
╵
╷
│ Error: creating Registry (Subscription: "XXXXXXX-XXXX-460d-8e3b-XXXXXXX"
│ Resource Group Name: "rg-acrdemo"
│ Registry Name: "acrprodregistrysieraclab001"): polling after Create: unexpected status 404 with error: ResourceNotFound: The Resource 'Microsoft.ContainerRegistry/registries/acrprodregistrysieraclab001' under resource group 'rg-acrdemo' was not found. For more details please go to https://aka.ms/ARMResourceNotFoundFix
│
│ with azurerm_container_registry.acr-prod,
│ on main.tf line 20, in resource "azurerm_container_registry" "acr-prod":
│ 20: resource "azurerm_container_registry" "acr-prod" {

Steps to Reproduce

1. terraform apply
   2 - 4 Resources created
   3 - Change the RG location
   4 - Reapply terraform apply

How much impact is this issue causing?

High

Logs

No response

Additional Information

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[bflad]

Hi @eliassal 👋 Thank you for reporting this issue and sorry you are running into trouble here.

While this error may have started with (new) usage of the hashicorp/null provider, the error messages in your report seems to be coming from or caused by the hashicorp/azurerm provider:

Provider produced inconsistent result after apply
╷
│ Error: Provider produced inconsistent result after apply
│
│ When applying changes to azurerm_container_registry.acr-dev, provider "provider["registry.terraform.io/hashicorp/azurerm"]" produced an unexpected new value: Root object was present,
│ but now absent.
│
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.
╵
╷
│ Error: creating Registry (Subscription: "XXXXXXX-XXXX-460d-8e3b-XXXXXXX"
│ Resource Group Name: "rg-acrdemo"
│ Registry Name: "acrprodregistrysieraclab001"): polling after Create: unexpected status 404 with error: ResourceNotFound: The Resource 'Microsoft.ContainerRegistry/registries/acrprodregistrysieraclab001' under resource group 'rg-acrdemo' was not found. For more details please go to https://aka.ms/ARMResourceNotFoundFix
│
│ with azurerm_container_registry.acr-prod,
│ on main.tf line 20, in resource "azurerm_container_registry" "acr-prod":
│ 20: resource "azurerm_container_registry" "acr-prod" {

There appear to be two errors there:

• For the development error, the error there is trying to say is that Terraform was expecting the azurerm_container_registry resource to successfully create a resource and save its state. The resource apparently returned no state and no error after that expectation, which triggered the Terraform error.
• For the production error, the error there appears to be coming from the hashicorp/azurerm provider and AzureRM service, which the developers of this provider would not have domain expertise in.

Both of these issues may very well be due to how the Terraform configuration is setup, but the hashicorp/azurerm provider developers would have domain knowledge about those particular details, if for example, the service has eventual consistency considerations which would cause strange behaviors when a creation operation occurs immediately near a deletion operation.

Since this doesn't immediately appear (or suggest to appear) to be an issue with this provider, which has very little surface area, I'm going to close this issue. There may be a few other threads to pull at though:

• Raising this report in the hashicorp/azurerm provider issue tracker (found by using the source code link in the registry): https://github.com/hashicorp/terraform-provider-azurerm/issues -- in particular, it might be good to double check with them about any service-level eventual consistency concerns
• General Terraform configuration questions can be asked on HashiCorp Discuss where there are many more practitioners asking and answering those types of questions
• Whether the behavior you're experiencing also occurs with the Terraform 1.4 and later terraform_data resource, which is effectively a built-in replacement for the null_resource resource.
• Whether the Terraform 1.2 and later lifecycle block replace_triggered_by argument might more fully remove any resource implementation from contributing to your issue (instead of the triggers attribute, which is part of the null_resource implementation).

Hope this helps and apologies there is not much more help we can provide as maintainers of this provider.

[github-actions]

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.