Azure KeyVault Error: Provider produced inconsistent result after apply

[GregBillings]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Terraform (and AzureRM Provider) Version

Terraform v0.14.8
AzureRM: terraform-provider-azurerm_v2.52.0_x5

Affected Resource(s)

• azurerm_key_vault_secret

Terraform Configuration Files

resource "azurerm_key_vault_secret" "mysecretvalue" {
  name         = "secretvaluename"
  value        = var.some_value_from_var
  key_vault_id = data.terraform_remote_state.remote_terraform_cloud_state.outputs.key_vault_id
}

Debug Output

Error: Provider produced inconsistent result after apply

When applying changes to azurerm_key_vault_secret.mysecretvalue,
provider "registry.terraform.io/hashicorp/azurerm" produced an unexpected new
value: Root resource was present, but now absent.

This is a bug in the provider, which should be reported in the provider's own
issue tracker.

Expected Behaviour

secret added to the keyvault

Actual Behaviour

The keyvault secret was added to the keyvault with the correct value, but the terraform apply failed with the error above. When re-running again, the new error is that the value already exists but isn't tracked in the terraform state

Steps to Reproduce

1. Create a terraform script that creates an azure keyvault and then outputs the ID as an output variable
2. Create another terraform script with a different remote state that pulls in the first remote state via:

data "terraform_remote_state" "remotestate" {
  backend = "remote"

  config = {
    organization = "my-org"
    workspaces = {
      name = "first-remote-state"
    }
  }
}

3. Attempt to create a new keyvault secret using the id from the output of the first remote state:

resource "azurerm_key_vault_secret" "mysecretvalue" {
  name         = "MySecretValue"
  value        = var.some_value_from_var
  key_vault_id = data.terraform_remote_state.remotestate.outputs.key_vault_id
}

References

• Error: Provider produced inconsistent result after apply #10227

[sinbai]

@GregBillings I am investigating this issue, but I can't repro it by following the steps below. Could you help confirm whether the following steps can repro this issue on your side? In addition, I would like to confirm whether you have done other operations before doing the following? Any detail information is greatly appreciated.

Steps to Reproduce

1. Create two new terraform cloud workspaces(ReproBug and ReproBug1).
2. Creates an azure keyvault on ReproBug workspace and then outputs the ID as an output variable via:

 terraform {
      required_providers {
        azurerm = {
          source = "hashicorp/azurerm"
         version = "2.52.0"
        }
      }
    
       backend "remote" {
       organization = "my-org-elena"
        workspaces {
          name = "ReproBug"
        }
     }
    }
    
    provider "azurerm" {
      features {}
    }
    
    resource "azurerm_resource_group" "test" {
      name     = "myTFResourceGroup"
      location = "westus2"
    }
    
    resource "azurerm_key_vault" "test" {
      name                       = "acctestkv-elena05"
      location                   = azurerm_resource_group.test.location
      resource_group_name        = azurerm_resource_group.test.name
      tenant_id                  = "XXXXXXXXX"
      sku_name                   = "standard"
      soft_delete_retention_days = 7
    
      access_policy {
        tenant_id = "XXXXXXX"
        object_id = "XXXXXXX"
    
        key_permissions = [
          "Get",
         "Delete",
        ]
    
        secret_permissions = [
          "Get",
          "Delete",
          "List",
          "Purge",
          "Recover",
          "Set",
        ]
      }
    
      tags = {
        environment = "Production"
      }
    }
    
    output "key_vault_id" {
      value = azurerm_key_vault.test.id
    }

3. create a new keyvault secret on ReproBug1 workspace using the id from the output of the first remote state via:

terraform {
      required_providers {
        azurerm = {
          source = "hashicorp/azurerm"
         version = "2.52.0"
        }
      }
    
       backend "remote" {
       organization = "my-org-elena"
        workspaces {
          name = "ReproBug1"
        }
     }
    }
    
    provider "azurerm" {
      features {}
    }
    
    data "terraform_remote_state" "remotestate" {
      backend = "remote"
    
      config = {
        organization = "my-org-elena"
        workspaces = {
          name = "ReproBug"
        }
      }
    }
    
    resource "azurerm_key_vault_secret" "mysecretvalue" {
      name         = "MySecretValue2"
      value        = "test"
      key_vault_id = data.terraform_remote_state.remotestate.outputs.key_vault_id
    }

Note: Remote state is managed by Terraform Cloud, issue can't be reproduced when Execution Mode is remote or local.

My Terraform (and AzureRM Provider) Version

[sinbai]

Have the same issue with azurerm v2.71
terraform 1.0.4

deleted the remote state and recreated from scratch and it worked fine. I previously upgraded from 2.70 -> 2.71 and terraform 1.0.1 -> 1.0.4

@elthanor I can't repro this issue, below is my repro steps. Could you provide more details to help me repro this issue?
1.Create two new terraform cloud workspaces(ReproBug1 and ReproBug2).
2.Create keyvault with azurerm v2.70 and terraform 1.0.1 on ReproBug1 workspace.
3.Update to azurerm provider to v2.7.1 and terraform to 1.0.4, add a new secret to the existing keyvault on workspace ReproBug2.

Note: Remote state is managed by Terraform Cloud, issue can't be reproduced when Execution Mode is remote or local.

[mybayern1974]

I would like to Re sinbai's finding that I cannot repro this issue either. The app I used is TF v1.0.5 and AzureRM provider v2.74 (this is the latest Azure provider version when I'm typing now). What I tried is creating a KV + KVSec first, and then use that created KV as a data source and create another KVSec. All the above was done by TF and all of them worked well w/o getting any command line error msg. I admit I just tried them w/ local state rather than remote state.

With noticing there are 20+ thump up to this issue, I do believe people ran into issues as described here. While to serve my or sinbai's troubleshooting, can anyone here provide more contexts in terms of step-by-step-repro-this-issue?

In addition, it would be helpful if below info can be provided:

1. Does this issue only repro when using remote state rather than local state?
2. Does this issue stable repro or happen intermittently?
3. For people who ran into this issue, do you use TF to manage all things (KV, KVSec, etc.) rather than using any other client tools (portal, CLI, etc) to co-manage resources?
4. For people who ran into this issue, is it possible there were someone-else/some-other-client-tooling manipulating the same resource (KV) at the same time when you used TF to manage that? If so, might this symptom be a result of conflict-manipulation-against-the-same-KV?

[MaksymChornyi]

@mybayern1974
Terraform 1.0.0
azurerm 2.71.0

1. I use backend "azurerm"
2. The problem occurs in ~70% of attempts
3. KeyVault has been created separately with the local state and I don't have this issue with the local state
4. We don't use KeyVault at the same moment

[futureviperowner]

When I ran into this issue, I was using a data resource to look up information about another key vault that was created outside of my terraform scripts. I was using the resource ID returned by the data source to create additional azurerm_key_vault_secret resources in that vault.

[mybayern1974]

@viper4u , I still could not repro after using remote states (use backend "azurerm") and using TF/AzureRM version you specified 😕. With seeing you mentioned 70% repro rate, I ran things 10 times and all of them succeeded.

Below are my repro steps with .tf config

1. Create a resource group on portal
2. Create a KV by TF with using backend=azurerm and TF ver=1.0.0 and AzureRM ver=2.71.0. Below is my config
   ===kv.tf===

terraform {
  backend "azurerm" {
    resource_group_name = "..."
    storage_account_name = "..."
    container_name = "..."
    key = "terraform1.tfstate"
  }
  required_providers {
    azurerm = {
      source = "hashicorp/azurerm"
      version = "2.71"
    }
  }
}

provider "azurerm" {
  features {}
}

data "azurerm_client_config" "current" {}

data "azurerm_resource_group" "test" {
  name     = "..."
}

resource "azurerm_key_vault" "test" {
  name                = "..."
  location            = data.azurerm_resource_group.test.location
  resource_group_name = data.azurerm_resource_group.test.name
  sku_name = "standard"
  tenant_id = data.azurerm_client_config.current.tenant_id

  access_policy {
    tenant_id = data.azurerm_client_config.current.tenant_id
    object_id = data.azurerm_client_config.current.object_id

    key_permissions = [
      "create",
      "get",
      "list",
      "purge"
    ]

    secret_permissions = [
      "set",
      "get",
      "delete",
      "purge",
      "recover",
      "list"
    ]
  }
}

===outputs.tf===

output "key_vault_id" {
  value = azurerm_key_vault.test.id
}

4. Execute terraform apply => A KV got provisioned
5. Create a KVSec by TF. Below is my .tf config
   ===kvsec.tf===

data "terraform_remote_state" "test" {
  backend = "azurerm"
  config = {
    storage_account_name = "..."
    container_name       = "..."
    resource_group_name  = "..."
    key                  = "terraform1.tfstate"
  }
}

resource "azurerm_key_vault_secret" "test" {
    name  = "..."
    value = "..."
    key_vault_id = data.terraform_remote_state.test.outputs.key_vault_id
}

6. Execute terraform apply => A KVSec got provisioned underneath the KV
7. Append below section to the kvsec.tf

resource "azurerm_key_vault_secret" "test2" {
    name  = "..."
    value = "..."
    key_vault_id = data.terraform_remote_state.test.outputs.key_vault_id
}

8. Execute terraform apply => Another KVSec got provisioned underneath the KV
9. Repeat step 7 - Step 8 for say 10 times => A bunch of KVSec got provisioned underneath the KV w/o seeing tf command line errors.

@doug-papenthien-by , I also did similar things by using local state and follow your "I was using the resource ID returned by the data source to create additional azurerm_key_vault_secret". While I still could not repro.

@ all here, do you see any usage/config difference between yours and mine above?

[sinbai]

@mybayern1974
Terraform 1.0.0
azurerm 2.71.0

1. I use backend "azurerm"
2. The problem occurs in ~70% of attempts
3. KeyVault has been created separately with the local state and I don't have this issue with the local state
4. We don't use KeyVault at the same moment

@viper4u Thank you for your reply. Below are my repro steps. The issue can't be reproduced. Could you follow the stpes below to reproduce it? If not, could you provide the step-by-step to help me reproduce this issue?

My Terraform (and AzureRM Provider) Version
Terraform 1.0.0
azurerm 2.71.0

Steps

1. Create a resource group named myTestResourceGroup on Azure portal.
2. Create a blob storage account named teststorageaccount on the Azure portal. (Stores the state as a Blob with the given Key within the Blob Container within the Blob Storage Account.)
3. Create a blob container named blobcontainer on the Azure portal.
4. Create a folder named ReproBug on the local machine and add a file named "step1.tf" in this folder.
5. Add the following tfconfig in step1.tf to create a azurerm_key_vault(Authenticate using a SAS Token associated with the Storage Account) :

terraform {
  required_providers {
    azurerm = {
      source = "hashicorp/azurerm"
     version = "2.71.0"
    }
  }

   backend "azurerm" {
    storage_account_name = "teststorageaccount"
    container_name       = "blobcontainer"
    key                  = "prod.terraform.tfstate1"

    sas_token = "XXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
  }
}


provider "azurerm" {
  features {}
}


resource "azurerm_key_vault" "test" {
  name                       = "acctestkv-elena0901"
  location                   = "westus2"
  resource_group_name        = "myTestResourceGroup"
  tenant_id                  = "XXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
  sku_name                   = "standard"
  soft_delete_retention_days = 7

  access_policy {
    tenant_id = "XXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
    object_id = "XXXXXXXXXXXXXXXXXXXXXXXXXXXXX"

    key_permissions = [
      "Get",
	  "Delete",
    ]

    secret_permissions = [
      "Get",
      "Delete",
      "List",
      "Purge",
      "Recover",
      "Set",
    ]
  }

  tags = {
    environment = "Production"
  }
}

output "key_vault_id" {
  value = azurerm_key_vault.test.id
}

6. Run terraform init、terraform plan、 terraform apply to create azurerm_key_vault.
7. Add a file named "step2.tf" in ReproBug folder.
8. Add the following tfconfig in step2.tf to create a azurerm_key_vault_secret(Authenticate using a SAS Token associated with the Storage Account):

terraform {
  required_providers {
    azurerm = {
      source = "hashicorp/azurerm"
     version = "2.71.0"
    }
  }

   backend "azurerm" {
    storage_account_name = "teststorageaccount"
    container_name       = "blobcontainer"
    key                  = "prod.terraform.tfstate2"

    sas_token = "XXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
  }
}

provider "azurerm" {
  features {}
}

data "terraform_remote_state" "remotestate" {
  backend = "azurerm"

  config = {
    storage_account_name = "teststorageaccount"
    container_name       = "blobcontainer"
    key                  = "prod.terraform.tfstate1"

    sas_token = "XXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
  }
}

resource "azurerm_key_vault_secret" "mysecretvalue" {
  name         = "MySecretValue-0901"
  value        = "test"
  key_vault_id = data.terraform_remote_state.remotestate.outputs.key_vault_id
}

9. After successfully creating azurerm_key_vault, run terraform init、terraform plan、 terraform apply to create azurerm_key_vault_secret=>azurerm_key_vault_secret was created,no command line error msg

10. Continue to add ten azurerm_key_vault_secrets with different key and different azurerm_key_vault_secret name to the azurerm_key_vault which created in step 6.=>All of them worked well, There is no command line error msg in my test

[MaksymChornyi]

@sinbai @mybayern1974
Sorry for the late answer
I tried to reproduce it with a simple script but I haven't faced the problem.
I have a failed attempt with a trace log level.
Where can I send it?

[sinbai]

@sinbai @mybayern1974
Sorry for the late answer
I tried to reproduce it with a simple script but I haven't faced the problem.
I have a failed attempt with a trace log level.
Where can I send it?

@viper4u Mail log to [email protected], thank you. I will try to see if there are any findings in the log, but I think step-by-step-repro-this-issue is the key to investigating this issue. Thank you very much.

[MaksymChornyi]

@sinbai
I've reproduced it with a simple script.
I have an Azure KeyVault and that issue is reproduced each time with that one
How can I help you to with it?

[sinbai]

@sinbai
I've reproduced it with a simple script.
I have an Azure KeyVault and that issue is reproduced each time with that one
How can I help you to with it?

Can I access that Azure KeyVault? And could you share your script (contains the access token) with me to reproduce it on my side?

[MaksymChornyi]

What did you mean by "access token"? I use Service Principal auth

[MaksymChornyi]

I've sent all details to your mail

[sinbai]

I've sent all details to your mail

Thank you. Per details provided, I cannot access the Azure KeyVault due to the access permissions.

[MaksymChornyi]

I've reproduced the issue with new keyvault
Context:

• Windows 10
• Terraform version: 1.0.6
• Service principle auth

Step to reproduce:

1. I am from East Europe
2. Create a new KeyVault in East US
3. Run simplest terraform script

terraform {

  backend "local" {
  }

  required_providers {
   
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~> 2.75.0"
    }
   
  }
}
provider "azurerm" {
  features {}
}

resource "azurerm_key_vault_secret" "test_key" {
  name         = "test"
  value        = "test"
  key_vault_id = "/subscriptions/<subscription_id>/resourceGroups/<rg-name>/providers/Microsoft.KeyVault/vaults/<vault_name>"
}

4. Secret has been created
5. Terraform output is "Error: Provider produced inconsistent result after apply"

[sinbai]

@viper4u Per the log provided, I found the Azure keyVault cannot be found after setting the secret, Could you help confirm whether the keyvault exists after reproducing this issue?

It is best to confirm through the following link：
https://docs.microsoft.com/en-us/rest/api/resources/resources/list#code-try-0

Notes:

1. Update the API version with 2020-06-01.
2. Add the optional parameter $filter with value resourceType eq 'Microsoft.KeyVault/vaults' and name eq '<kv name>' like this:
   
3. Try it several times to see if you can find it every time.

In addition, could you also check the total resources count of your subscription?

[MaksymChornyi]

Results

1. when I use the filter with "and name eq ''", then I get
   { "value": [], "nextLink": "<some_url>" }
2. when I use the filter without "and name eq ''", then I get list of resources with my KeyVault
3. When I try another Keyvault in another subscription then I get result without nextlink
   { "value": [ { "id": "/subscriptions/<my_subscription>/resourceGroups/<rg_name>/providers/Microsoft.KeyVault/vaults/<kv_name>", "name": "makctestkv3", "type": "Microsoft.KeyVault/vaults", "location": "eastus2" } ] }

[sinbai]

Results

1. when I use the filter with "and name eq ''", then I get
   { "value": [], "nextLink": "<some_url>" }
2. when I use the filter without "and name eq ''", then I get list of resources with my KeyVault
3. When I try another Keyvault in another subscription then I get result without nextlink
   { "value": [ { "id": "/subscriptions/<my_subscription>/resourceGroups/<rg_name>/providers/Microsoft.KeyVault/vaults/<kv_name>", "name": "makctestkv3", "type": "Microsoft.KeyVault/vaults", "location": "eastus2" } ] }

Could you please share with me the screenshot of the above results and obscure sensitive information(Including parameter settings and respond body)?

[sinbai]

I submitted a PR that might solve this issue. Since I can’t reproduce this problem until now, I can’t verify it. Is anyone willing to build it and verify that this issue is fixed? The info to build a TF provider (on Windows) are as follows:

Requirements:
Terraform version 0.12.x + (but 1.x is recommended)
Go version 1.16.x (to build the provider plugin)
Git Bash for Windows
Make for Windows

Using the locally compiled Azure Provider binary:
For example, add the following to terraform.rc for a provider binary located in D:\GoCode\bin. The file named terraform.rc and placed in the relevant user's %APPDATA% directory.

Steps:

1. Pull this PR
2. Run make build in git bash.

After make build is completed, it will be used automatically when running terraform apply.

References:
https://github.com/hashicorp/terraform-provider-azurerm/blob/main/README.md

[Nemeczek]

@Nemeczek do you have Key vault on a different subscription where you are creating resource. In this call, use module and change provider when calling it

everything is in one sub. only in different resource groups

[Nemeczek]

@Nemeczek do you have Key vault on a different subscription where you are creating resource. In this call, use module and change provider when calling it

I just did that and it worked. It is literally copy paste from main module (I am using Azure CLI context as auth)
to the module that needs to create secret.

provider "azurerm" {
  features {}
  skip_provider_registration = true
}

[magodo]

@Nemeczek Could you please try out my local branch of the provider, which changes the way of how to determine the Resource ID for the Key Vault at URL? To use that branch, please checkout it locally, and install it to somewhere. Then follow this page to setup terraform to using the locally built provider.

If that works, then please let us know.

[pearcec]

FWIW, we experienced this a lot, we have taken to this workaround, this gets added to all our automation. Azure's response has been use Graph API. It seems that the eastus is the primary for Keyvault lookups since it is a global resource (not 100% sure). It seems to work regardless of the region.

 sudo echo "$(host eastus.management.azure.com | tail -1 | awk '{ print $NF }') management.azure.com" | sudo tee -a /etc/hosts

[rvplauborg]

I just experienced this issue, where the workaround of adding an aliased provider with same subscription as my default provider, and adding that provider to key vault and key vault secrets resources fixed the issue.

[llohrstraeter]

Having the same issue. I use a module with multiple providers that contains two more modules. One of them is provisioning a keyvault in subscription A, the other one looks up a keyvault using a datasource from subscription B.

When removing the module that fetches the keyvault from sub B, the deployment of keyvault to sub A works fine.
When adding the module fetching the keyvault from sub B, deployment of keyvault to sub A fails because it tries to fetch the resource group from sub B instead of sub A.
The strange thing is that I don't even pass the provider for sub B to the module that deploys the keyvault to sub A. No clue why it is checking the wrong one.

Even though the apply fails the keyvault is deployed properly to sub A and I get an error that it already exists when running another apply.

Using TF version 1.3.6 with azurerm V3.34.0, happy to provide trace logs if needed.

Edit: Adding an additional provider that basically mirrors the default provider for the key vault as suggested above solves the issue.

[rezarms]

I upgrade azurerm to 3.41 and fixed the issue

[vamshisiram]

I am getting the same issue with azurerm_service_plan resource.

I use a module to deploy a bunch of apps, everything works fine expect the app service plan resource fails with this error.

if I run a plan/apply again it says a resource with same name already exists. When I refresh the azure portal, I see it. I deleted the app service plan from portal and retry this again, it fails with same error. It is a loop.

It appears as if terraform is not able to reach azure api in time to see the created resource.

I use three different providers in the module.

I am using terraform 1.3.9 and azurerm version 3.45.0.

it worked fine until few days ago with version 3.2.0 and it stopped working all of a sudden. I opened a support case with hashicorp and their recommendation is to use version latest of azurerm. So, I did that and it still does not work.

pls help with this issue.

[bricksterlad]

I was getting the same error with azurerm version 3.13.0, then I moves to 3.45.0 and I managed to create the resource without getting an error. But now when I run a terraform apply the second time, it tries to create the same resource a second time , so I get an error that the resource already exists. When I checked the state file, I couldn't find the resource there after the second apply (it was there after the first successful apply)
I would appreciate any help regarding this

[akorp]

Thanks everyone for info here in this issue.

Having different subscriptions in key_vault_id and azurerm provider for resource "azurerm_key_vault_secret" probably cause inconsistency in our case.

We also had this error:

│ Error: Provider produced inconsistent result after apply
│ 
│ When applying changes to
│ module.service_principal.azurerm_key_vault_secret.service_principal_password,
│ provider "provider[\"registry.terraform.io/hashicorp/azurerm\"]" produced
│ an unexpected new value: Root resource was present, but now absent.
│ 
│ This is a bug in the provider, which should be reported in the provider's
│ own issue tracker.
╵

In our case we use two providers for 2 different subscription - default and second. We got reference to a key vault in the second subscription with specifying provider.

data "azurerm_key_vault" "kv_1" {
  provider = azurerm.second

  name                = kv_name
  resource_group_name = rg_name
}

This key vault ID was later used in a module to create resource "azurerm_key_vault_secret" where we didn't specify any provider so a default provider was used.

The fix was to pass provider to the module, so the second provider is used inside the module to create resource "azurerm_key_vault_secret"

module "service_principal" {
  source = "url"

  providers = {
    azurerm = azurerm.second
  }

...

[rmcolbert]

We are experiencing the same kind of issue with the azurerm_app_service_certificate resource. We're passing in the fully qualified certificate secret ID (the only resource input related to the KV) but since the API to create call to Microsoft.Web/certificates requires the KV's resource ID, the provider has to try and resolve the resource ID. This is a big issue for us because the App Service Certificate will always be in a different subscription from the KV.

In our case, if the azurerm_app_service_certificate accepted either kv_cert_secret_id or {kv id + cert name}, we could get around this ... or just a way to pass in the kv subscription id for it to use in the id resolution.

[michelefa1988]

I randomly for this error on one of our environments. Worked around by adding the lock manually into the statefile

[nadworny]

I was getting the same error with azurerm version 3.13.0, then I moves to 3.45.0 and I managed to create the resource without getting an error. But now when I run a terraform apply the second time, it tries to create the same resource a second time , so I get an error that the resource already exists. When I checked the state file, I couldn't find the resource there after the second apply (it was there after the first successful apply) I would appreciate any help regarding this

same here, when running it for the second time, I get the "already exists" error. Using azurerm 3.105.0. I haven't verified that but the error might be thrown when the secret was already once deleted.

[tombuildsstuff]

👋 hey folks

We've recently updated the behaviour of the Key Vault cache such that we check both the Key Vaults List API and the same (old) Resources API that the current version of Azure CLI is currently using - and as such it'd be good to hear if this is still being encountered when using the latest version of the Provider? This fix is included in v3.106.0 and above (although v3.107.0 is the latest at the time of writing) - if you're able to would you mind updating to the latest version of the Provider and letting us know if that works for you?

Thanks!

[serbezki]

I just hit this problem with version 3.108 of the provider.

[nadworny]

I tried it with 3.108 and it still doesn't work

[DevopsMercenary]

I've been experiencing this issue for a while.. Here's my current state
Terraform v1.9.4
on darwin_arm64

• provider registry.terraform.io/hashicorp/azuread v2.53.1
• provider registry.terraform.io/hashicorp/azurerm v3.116.0
• provider registry.terraform.io/hashicorp/time v0.12.0

[DevopsMercenary]

In my case I am using a time_rotating provider to set the expiration_date

resource "time_rotating" "avd_registration_expiration" {
  # Must be between 1 hour and 30 days
  rotation_days = 29
}

resource "azurerm_virtual_desktop_host_pool_registration_info" "default" {

  hostpool_id     = data.azurerm_virtual_desktop_host_pool.default.id
  expiration_date = time_rotating.avd_registration_expiration.rotation_rfc3339

}

resource "azurerm_key_vault_secret" "registration-key" {

  name = "${data.azurerm_virtual_desktop_host_pool.default.name}-registration-key"

  value = azurerm_virtual_desktop_host_pool_registration_info.default.token

  key_vault_id = data.azurerm_key_vault.default.id

  expiration_date = time_rotating.avd_registration_expiration.rotation_rfc3339


}

[fy-openai]

we're still seeing this with v3.109.0. A similar one is mentioned here: #24948. And a potential fix was made here: hashicorp/go-azure-sdk#927 not for terraform-provider-azurerm, but for pandora.

The root cause IMO is nextLink is not read(unmarshalled) properly from http repsonse, effectively causing the ExecutePaged function to return prematurely, leading ListBySubscriptionComplete to return 10(default size of a list call) keyvaults instead of the full list. The same thing applies to ListComplete, which has a bigger default size: 24.

I verified locally that changing "NextLink *Link json:"@odata.nextLink"" here to "NextLink *Link json:"nextLink"" fixes the issue in our case, but there must be more nuances that need to be considered to make the fix robust.

[teowa]

Hi @fy-openai , the custom pager ( x-ms-pageable.nextLinkName ) was handled in hashicorp/go-azure-sdk PR hashicorp/go-azure-sdk#1039 on Jun 28, and this was introduced to Azurerm at PR #26502 , released at 3.111.0 version (Jul 4) , so after this version the issue should be resolved.

[trevorcreech]

Confirmed fixed for me on 3.111.0

[DevopsMercenary]

Ran into this issue again. Current versions include

Terraform v1.9.8
on darwin_arm64
+ provider registry.terraform.io/hashicorp/azuread v3.0.2
+ provider registry.terraform.io/hashicorp/azurerm v4.7.0
+ provider registry.terraform.io/hashicorp/time v0.12.1