terraform-provider-azurerm: azurerm_api_management fails to apply on 3.10.0 provider

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 “+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 Version

1.2.1

AzureRM Provider Version

3.10.0

Affected Resource(s)/Data Source(s)

azurerm_api_management

Terraform Configuration Files

resource "azurerm_api_management" "hogarth_api_management" {
  depends_on = [azurerm_key_vault_access_policy.user_assigned_managed_identity_001]

  name                          = "${var.opp_grp}-${var.proj_code}-${var.locale}-${var.sn_env}-apim-001"
  location                      = var.location
  resource_group_name           = var.resource_group_name
  publisher_name                = "Hogarth"
  publisher_email               = "hogarth@hogarthww.com"
  public_network_access_enabled = true
  sku_name                      = var.sn_env == "p" ? "Premium_1" : "Developer_1"
  zones                         = var.sn_env == "p" ? [1, 2, 3] : null
  virtual_network_type          = "Internal"

  virtual_network_configuration {
    subnet_id = azurerm_subnet.pwapimgw_apimanagement_subnet.id
  }

  identity {
    type = "SystemAssigned"
  }

  certificate {
    encoded_certificate  = filebase64("../certificates/${var.automation_cert_name}.crt")
    certificate_password = ""
    store_name           = "Root"
  }

  tags = merge(local.tags, {
    hostname    = "${var.opp_grp}-${var.proj_code}-${var.locale}-${var.sn_env}-apim-001"
    serverrole  = "N/A"
    serveros    = "N/A"
    servicename = "api_management"
  })
}

Debug Output/Panic Output

azurerm_api_management.hogarth_api_management: Still creating... [32m30s elapsed]
azurerm_api_management.hogarth_api_management: Still creating... [32m40s elapsed]
azurerm_api_management.hogarth_api_management: Still creating... [32m50s elapsed]
azurerm_api_management.hogarth_api_management: Still creating... [33m0s elapsed]

Error: waiting for recovery of "Api Management: (Service Name \"hgh-pwapimgw-weuro-d-apim-001\" / Resource Group \"pwapimgw-d-app-rg\")": pollingTrackerPut#checkForErrors: the response did not contain a body: StatusCode=0

  with azurerm_api_management.hogarth_api_management,
  on api_management.tf line 1, in resource "azurerm_api_management" "hogarth_api_management":
   1: resource "azurerm_api_management" "hogarth_api_management" {" {

Expected Behaviour

The APIM resource should apply.

Actual Behaviour

The apply runs for ~30mins and then fails, however the resource is seen in the Azure portal.

The ~30min runtime is expected.

This worked fine on provider 3.9.0.

It fails on 3.10.0 (which appears to have had changes to the azurerm_api_management resource in it.

Steps to Reproduce

Setup the terraform code as per above and run an apply.

Important Factoids

Worked fine on provider 3.9.0

References

No response

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Reactions: 34
  • Comments: 24 (3 by maintainers)

Most upvoted comments

Can confirm this is an issue. Have been trying ALL week to get APIM deployed with terraform and finally found this by googling the error message - it consistently fails on 3.10.0 - apim actually get’s created but when the procedure fails my API’s which are also part of the deployment (and depend on APIM) are not deployed

Same issue with version = “3.44.1” pollingTrackerPut#checkForErrors: the response did not contain a body: StatusCode=0

the response did not contain a body: StatusCode=0 for apim in 3.35.0 version can any one help

Same issue with version 3.50.0

waiting for recovery of "Api Management: (Service Name): pollingTrackerPut#checkForErrors: the response did not contain a body: StatusCode=0

Workaround: Let it fail with this error message (The resource is actually created on failure) and then run a terraform import [resource.name] [ResourceID] rerun your apply and it should be happy

Same issue with version 3.49.0

waiting for recovery of "Api Management: (Service Name "xxxx") pollingTrackerPut#checkForErrors: the response did not contain a body: StatusCode=0

any workaround for this ?

same issue here using v3.31.0 - 33m30s later - waiting for recovery of “Api Management” pollingTrackerPut#checkForErrors: the response did not contain a body: StatusCode=0

same issue with me

Same issue in v3.38.0.

azurerm_api_management.api_management: Still creating… [35m26s elapsed]

Error: waiting for recovery of “Api Management: (Service Name \apim" / Resource Group "front-01")”: pollingTrackerPut#checkForErrors: the response did not contain a body: StatusCode=0

same with v3.37.0

Same here with v3.36.0. Deployment fails after ~1h4m with the error pollingTrackerPut#checkForErrors: the response did not contain a body: StatusCode=0

Still experiencing this issue with 3.29.1. Fails to complete action after 1 hour and processing of other resource deployments is cancelled, yet apim resource appears in RG. I have been purging soft-delete between deployments.

azurerm_api_management.apim: Still creating... [59m1s elapsed]
##[error]The operation was canceled.

I also had this issue. Azure introduces a soft delete for Azure API Management. When the service was not purged the API call to create or update the service will fail. So for future versions, we need an option to enable the purge when the APIM gets deleted or recover the soft-deleted instance. This problem probably occurs when you deleted the APIM via the UI for some reason.

The workaround for me was to purge the service manually.

Edit: I just scrolled to the issues and discovered that the feature is already in place. But it just seems to don’t work, see https://github.com/hashicorp/terraform-provider-azurerm/issues/17662 So this might be closed in favor of the other bug ticket.