azurerm_api_management_api: changing from single version api to api with multiple versions causes "already exists" on first apply #28048
Comments
|
Thank you @J0F3 for reporting this APIM issue. It seems different from the creation provisioning poller issue since the delete doesn't appear to be a long-running operation at first glance. However, I'm not certain yet and will investigate further when I have the chance. |
|
Thank you @wuxu92 . What I also noticed is that it really takes some time (approx. 1sec in my case but is probably depending on the size/complexity of th api) until the api really gone on the APIM. That's also what actually causes the issue (because the GET request come to early). May this help to further investigations. |
Well with that said I cannot reproduce 202 answers with the api version "2022-08-01" anymore 😵. I get always just a 200. |
|
@J0F3 Yes, the latest stable version |
|
Yes, but something seems to be strange with the api version 2024-05-01 also. |
|
This is a known issue with the API version. The service team provided "an estimated completion of the fix in the second week of January." We need a custom poller in the provider before the service team fixes it. |
|
Ah ok, good to know. Thx! |
|
@J0F3 I tested this configuration on my machine and found that the issue is not caused by an API problem, but by the overlapping order of API deletion and additional_api creation. When we change
|
|
@wuxu92 Thank you. So, this basically means that it cannot be fixed in the provider itself, right? Instead, it must be ensured by an explicit Or do you have any other suggestion for fixing the error? Thx! |
|
I tested it quickly by adding provider "azurerm" {
resource_provider_registrations = "none"
features {}
}
locals {
apim_rg = "test-rg"
apim_name = "test-apim"
additional_version = false
}
resource "azurerm_api_management_api_version_set" "additional_version" {
name = local.apim_name
api_management_name = local.apim_name
resource_group_name = local.apim_rg
display_name = "replace-api-bug-repro"
versioning_scheme = "Header"
version_header_name = "Version"
}
resource "azurerm_api_management_api" "api" {
name = local.additional_version == true ? "replace-api-bug-repro-cloud" : "replace-api-bug-repro"
resource_group_name = local.apim_rg
api_management_name = local.apim_name
revision = "1"
display_name = "replace-api-bug-repro - ${local.additional_version ? "multi version" : "single version"}"
path = "test/api"
protocols = ["https"]
import {
content_format = "openapi"
content_value = file("${path.module}/openapi.yaml")
}
version_set_id = local.additional_version ? azurerm_api_management_api_version_set.additional_version.id : null
version = local.additional_version ? "cloud" : null
}
resource "azurerm_api_management_api" "additional_api" {
count = local.additional_version ? 1 : 0
name = "replace-api-bug-repro"
resource_group_name = local.apim_rg
api_management_name = local.apim_name
revision = "1"
display_name = "replace-api-bug-repro - ${local.additional_version ? "multi version" : "single version"}"
path = "test/api"
protocols = ["https"]
import {
content_format = "openapi"
content_value = file("${path.module}/openapi.yaml")
}
version_set_id = azurerm_api_management_api_version_set.additional_version.id
version = null
depends_on = [ azurerm_api_management_api.api ]
}
In this particular test case, the error form #23322 did not occurred for me. But I am very aware of this issue. We have these errors almost on daily basis somewhere. 🙈 @wuxu92 Thank you very much for looking into it and for giving the hint where the cause actually is! |
|
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. |
Is there an existing issue for this?
Community Note
Terraform Version
1.9.8
AzureRM Provider Version
4.10.0
Affected Resource(s)/Data Source(s)
azurerm_api_management_api
Terraform Configuration Files
Debug Output/Panic Output
https://gist.github.com/J0F3/5ec2d9c1d4425b871271b56a89a55ab5
Expected Behaviour
azurerm_api_management_api should be replaced as shown in
terraform planwithout any error.Actual Behaviour
The first time running
terraform applyalways fails with 'A resource with the ID ... already exist...'. The second time runningterraform applyworks then and completes the needed changes. But in a CI/CD pipeline this always leads to a broken pipeline and needs retries.The reason for that is similar to the reason of #23322 where azurerm does not follow correctly the polling URL of the Azure API where a long running operation should be tracked. Instead azurerm zu goes ahead and tries to create the api again (with the new setting) but then it finds the previous API for which the delete operation has not finished yet.
Here is the relevant part of the debug log:
Here it is clearly visible that the DELETE Call was made to the Azure API and then immediately after that the certation starts which find then API which is going to be deleted. It can identified by the "displayName" of the API which contains still "single version" which is the API which must be deleted. I added the string to the "displayName" by intent so that it can be tracked which version of the api is the one which actually triggers the conflict.
As you can see in the documentation of the Azure API the DELETE resource normally response with "202" and URLs where the actual progress can be tracked: https://learn.microsoft.com/en-us/rest/api/apimanagement/apis/delete?view=rest-apimanagement-2024-05-01&tabs=HTTP#apimanagementdeleteapi
But this response seems to be ignored by azurem. So, it similar to what happens in #23322 for which PR with a fix is still pending: hashicorp/go-azure-sdk#1090. So maybe this would also be fixed when the PR is merged. But I am not sure. @wuxu92 Can please confirm/verify that?
Steps to Reproduce
local.additional_version=falselocal.additional_version=falsetolocal.additional_version=true. Plan show now that the api must be replaced which makes sense:terraform apply) then it would fail with:terraform applyis run the apply succeeds then.Important Factoids
No response
References
I think this is also related to hashicorp/go-azure-sdk#1090
The text was updated successfully, but these errors were encountered: