Terraform-provider-azurerm: Removing app service outside terraform causes plan failure

[hbuckle]

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.11.11
terraform-provider-azurerm_v1.21.0

Affected Resource(s)

azurerm_app_service

Terraform Configuration Files

resource "azurerm_resource_group" "resource_group" {
  name     = "hbtest_webapp_vnet"
  location = "uksouth"
}

resource "azurerm_app_service_plan" "app_service_plan" {
  name                = "hbtest_webapp_vnet"
  location            = "${azurerm_resource_group.resource_group.location}"
  resource_group_name = "${azurerm_resource_group.resource_group.name}"

  sku {
    tier = "Standard"
    size = "S1"
  }
}

resource "azurerm_app_service" "app_service" {
  name                = "hbtestwebappvnet1"
  location            = "${azurerm_resource_group.resource_group.location}"
  resource_group_name = "${azurerm_resource_group.resource_group.name}"
  app_service_plan_id = "${azurerm_app_service_plan.app_service_plan.id}"
}

Debug Output

Expected Behavior

• Apply the above config
• Delete the web app (leaving the app service plan) from the Azure portal
• Run terraform plan

Expected terraform to report the web app needs to be recreated

Actual Behavior

azurerm_app_service.app_service: Error making Read request on AzureRM App Service Configuration "hbtestwebappvnet1": web.AppsClient#GetConfiguration: Failure responding to request: StatusCode=404 -- Original Error: autorest/azure: Service returned an error. Status=404 Code="ResourceNotFound" Message="The Resource 'Microsoft.Web/sites/hbtestwebappvnet1' under resource group 'hbtest_webapp_vnet' was not found."

Notes

This may be a bug in the Go SDK as the web app client seems to not return an error when the web app does not exist.
this should handle things, but doesn't. Adding these three lines gives the following debug output

log.Printf("[DEBUG] %s", err)
log.Printf("[DEBUG] %s", resp.Response.Status)
log.Printf("[DEBUG] %d", resp.Response.StatusCode)

2019-01-17T15:35:35.568Z [DEBUG] plugin.terraform-provider-azurerm_v1.21.0_x4.exe: 2019/01/17 15:35:35 [DEBUG] %!s(<nil>)
2019-01-17T15:35:35.568Z [DEBUG] plugin.terraform-provider-azurerm_v1.21.0_x4.exe: 2019/01/17 15:35:35 [DEBUG] 404 Not Found
2019-01-17T15:35:35.568Z [DEBUG] plugin.terraform-provider-azurerm_v1.21.0_x4.exe: 2019/01/17 15:35:35 [DEBUG] 404

[sandeepkram]

I am having the exact same issue :

I created a resource group with app service plans and app service via terraform and then had to delete the resource groups entirely via the ARM - now the plan always fails in TF. Same error as above.

Any workaround ?

[r0bnet]

I'm not sure if this is related but i have the problem that when i add an entry in the app_settings manually then it will be overridden by terraform although it's not in it's state. Seems to be a bug in my opinion.
Why i think this may be related is that TF reaches out to the resource even though it does not need to and could look the app_settings in the state in the plan phase.

[gettek]

I believe this has been addressed in v1.25.0

[joshfriend]

I'm having the exact same problem (on v1.28.0) except the resource I'm trying to create has _never existed_.

[neil-yechenwei]

After tested with repro steps you provided, seems the issue has gone. If you have time, could you help to double check whether the issue still exists? Thanks.

[ArcturusZhang]

Hi all, indeed the SDK is returning nil error when it receives 404. The root cause is here in the azure-rest-api-specs.

Some context:
When we are generating the SDK from rest api specs, a responses block defines all the status codes that SDK would NOT return an error. In this case, 404 is listed in this response block, therefore the SDK will not return errors when it receives 404.