Skip to content

Bug: terraform destroy fails due to trailing slash parsing in response from the provided metadata_host #29819

@cdalsoniii

Description

@cdalsoniii

Is there an existing issue for this?

  • I have searched the existing issues

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 comments along the lines of "+1", "me too" or "any updates", 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 and review the contribution guide to help.

Terraform Version

1.3.9

AzureRM Provider Version

4.3.0

Affected Resource(s)/Data Source(s)

all resources

Terraform Configuration Files

N/A

Debug Output/Panic Output

N/A

Expected Behaviour

Expected Behavior:

terraform destroy should successfully remove the deployed Azure resources, with the standard metadata_host configured; with or without a trailing slash added to the resource managerendpoint. The provider should handle the trailing slash gracefully.

Actual Behaviour

terraform destroy fails with an error similar to (exact error message may vary depending on the specific API call failing, but the root cause is the malformed URL, specific error described above). The terraform destroy will fail to update state and let terraform know the destroy occurred and as a result retries to delete the resources on a loop:

Steps to Reproduce

Reproduction Steps:

Configure AzureRM Provider: Ensure your provider "azurerm" block explicitly sets the resource manager endpoint metadata_host with what is provided for that environment (management.azure.com). 

For example:

Terraform

provider "azurerm" {
  features {}
  # ... other configuration ...
  metadata_host = "management.azure.com" # Must be the standard endpoint for that environment (gov or public)
}

Deploy Resources: Create a main.tf (or similar) with any Azure resource. For demonstration, a simple resource group is sufficient:

Terraform

resource "azurerm_resource_group" "example" {
  name     = "my-resource-group-to-destroy"
  location = "East US"
}

Initialize and Apply:

Bash

terraform init
terraform apply --auto-approve

Attempt Destroy:

Bash

terraform destroy --auto-approve

Expected Behavior:

terraform destroy should successfully remove the deployed Azure resources, with the standard metadata_host configured; with or without a trailing slash added to the resource managerendpoint. The provider should handle the trailing slash gracefully.

Important Factoids

No response

References

Labels: bug, azurerm provider, terraform destroy

Environment:

Terraform Version: v1.3.9, v1.12
AzureRM Provider Version: (4.3.0 - 4.30)
Operating System: (Ubuntu 20.04.6)
Cloud: Azure Public Cloud

TLDR;

We are requesting that the ResourceManager entry to be sanitized to be without the trailing /. Values from management.azure.com and from govcloud - e.g."resourceManager": "https://management.azure.com/
"resourceManager": "https://management.usgovcloudapi.net",
This is in Public cloud has a trailing /, but not gov cloud does not. This only impacts the provider if you are using the metadata_host parameter. Hypothesis is that the api endpoints is a concatenation of the resource manger endpoint and the API path resulting in APIs calls with // like https://management.azure.com//subscription/subscription-id/resourcegroup/resourcegroupid/resourcetype.
When a delete is issued, the provider breaks down the URI into key value pairs based on the slash and that results in the pairs being "": subscription, subscription_id: resouce:group, resource_group_id: resource_type which is reconstituted to///subscription/subscription_id/resource_group/resource_group_id/resource_type.
When a GET is performed against that url, it always returns a 200 and the list of resources of that type. Because the wrong URL is being watched, it will never return a 404 and TF will eventually timeout.

Description:

When attempting to run terraform destroy with the azurerm provider, the operation consistently fails. After investigation, it appears the provider is incorrectly parsing one of the key value pairs from is returned by the provided metadata_host because of how it parses a value (resource manager) that contains a trailing slash, leading to malformed API requests during the destroy process.

Reproduction Steps:

Configure AzureRM Provider: Ensure your provider "azurerm" block explicitly sets the resource manager endpoint metadata_host with what is provided for that environment (management.azure.com). 

For example:

Terraform

provider "azurerm" {
  features {}
  # ... other configuration ...
  metadata_host = "management.azure.com" # Must be the standard endpoint for that environment (gov or public)
}

Deploy Resources: Create a main.tf (or similar) with any Azure resource. For demonstration, a simple resource group is sufficient:

Terraform

resource "azurerm_resource_group" "example" {
  name     = "my-resource-group-to-destroy"
  location = "East US"
}

Initialize and Apply:

Bash

terraform init
terraform apply --auto-approve

Attempt Destroy:

Bash

terraform destroy --auto-approve

Expected Behavior:

terraform destroy should successfully remove the deployed Azure resources, with the standard metadata_host configured; with or without a trailing slash added to the resource managerendpoint. The provider should handle the trailing slash gracefully.

Actual Behavior:

terraform destroy fails with an error similar to (exact error message may vary depending on the specific API call failing, but the root cause is the malformed URL, specific error described above). The terraform destroy will fail to update state and let terraform know the destroy occurred and as a result retries to delete the resources on a loop:

Error: ...
 

Potential Cause (Hypothesis):

It appears the azurerm provider's internal URL construction logic might be concatenating the metadata_host with resource-specific paths without correctly normalizing or stripping potential trailing slashes from the base endpoint, leading to double slashes in the final API request URL (e.g., https://management.azure.com//subscriptions/...).

Workaround (if applicable):

Currently, the only known workaround is to remove the trailing slash from the ResourceManager in the response from the metadata_host in the provider configuration when mocking the metadata endpoint:

Bash

// Mock the response from the metadata_host using a custom metadata_host
// Set the resource manager api endpoint within the mock data so as to resolve the conflict from the lack of correct parsing.

While this allows terraform destroy to succeed, it should not be necessary and indicates a bug in the provider's URL handling.

Request:

Please investigate and fix the parsing of themetadata_host response to correctly handle trailing slashes, ensuring terraform destroy operates reliably regardless of this configuration detail.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions