azurerm_linux_function_app zip deploy failures do not result in a tainted resource

[lkanerv]

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 and review the contribution guide to help.

Terraform Version

1.5.7

AzureRM Provider Version

3.86.0

Affected Resource(s)/Data Source(s)

azurerm_linux_function_app

Terraform Configuration Files

Use the azurerm_linux_function_app resource with the zip_deploy_file argument and remote build settings:

resource "azurerm_linux_function_app" "example" {
  name                = "example-function-app-name"
  resource_group_name = azurerm_resource_group.example.name
  location            = azurerm_resource_group.example.location

  storage_account_name       = azurerm_storage_account.example.name
  storage_account_access_key = azurerm_storage_account.example.primary_access_key
  service_plan_id            = azurerm_service_plan.example.id
  zip_deploy_file            = var.zip_deploy_file_path

  site_config {}
  app_settings.              = {      
    ENABLE_ORYX_BUILD              = "true"
    SCM_DO_BUILD_DURING_DEPLOYMENT = "true"
  }
}

Debug Output/Panic Output

When a value for zip_deploy_file is provided and the zip deploy fails (in our case, due to transient Azure network issues described below), the azurerm_linux_function_app resource does not get tainted, and fails to create, according the terraform apply output. Some examples of transient errors we've seen from Azure during zip deployments:

Error: publishing source (function_app.zip to site example-function-app-name 
(Resource Group example-resource-group): sending publish request: 
Post "https://example-function-app-name.scm.azurewebsites.net/api/zipdeploy?isAsync=true": 
read tcp example-ip:example-port->example-ip:example-port: read: connection reset by peer

and

│ Error: publishing source (function_app.zip) to site example-function-app-name 
(Resource Group example-resource-group): sending publish request: 
Post "https://example-function-app-name.scm.azurewebsites.net/api/zipdeploy?isAsync=true": 
dial tcp: lookup example-function-app-name.scm.azurewebsites.net on exampleip:exampleport: no such host

terraform apply fails as a result of the above errors, however the function app is still created on Azure. This means that the resource exists in Azure and is not being tracked by terraform state. Subsequent terraform apply runs then fail with:

│ A resource with the ID
│ "/subscriptions/example-subscription-id/resourceGroups/example-resource-group/providers/Microsoft.Web/sites/example-function-app-name"
│ already exists - to be managed via Terraform this resource needs to be
│ imported into the State. Please see the resource documentation for
│ "azurerm_linux_function_app" for more information.

Expected Behaviour

When a zip_deploy_file is provided and the zip deploy fails, terraform-provider-azurerm should taint the azurerm_linux_function_app resource, since Azure still creates the function app. Tainting the resource ensures that the azurerm_linux_function_app resource is properly tracked in terraform state, and is marked for destruction and re-creation on the next terraform apply run.

Actual Behaviour

When the zip_deploy_file argument is used with azurerm_linux_function_app and the zip deployment fails, the creation of azurerm_linux_function_app is considered failed during a terraform apply and the resource is not tracked in terraform state. However, the function app has been created in Azure, even though the zip deploy failed. Subsequent terraform apply runs fail due to the resource already existing.

The broken function app must then be manually deleted outside of Terraform to resolve the "resource already exists" issue.

Steps to Reproduce

1. Configure an azurerm_linux_function_app resource and provide a deployment zip file, zip_file_deploy
2. terraform apply
3. Hit a transient Azure network error with zip deployments (or find some way to simulate a failed zip deployment)
4. Check Azure Portal and notice that while terraform apply has failed, Azure has still created the function app
5. Run terraform apply again and see that the created azurerm_linux_function_app is not being tracked by terraform state, hit a "resource already exists" error

Important Factoids

Workaround: Use a provisioner local-exec command to run a zip deployment, since creation-time provisioners mark resources as tainted upon failure

References

No response

[lkanerv]

The workaround I've found to this bug is to use a creation-time provisioner within the azurerm_linux_function_app resource. The provisioner runs a zip deployment command with the Azure CLI.

If the zip deploy command fails, the creation-time provisioner ensures that the function app is marked as tainted, and then the function app is replaced on the next terraform apply run.

[kumy]

@katbyte Thanks for fixing this, however the new behavior seem also bugged.

Publishing the zip file failed with error

╷
│ Error: publishing source (release.zip) to site App Service (Subscription: "xxx"
│ Resource Group Name: "xxxxx"
│ Site Name: "xxxxxx"): waiting for Zip Deployment to complete
│ 
│   with module.xxx.module.xxx["centralus"].azurerm_linux_function_app.function_app,
│   on azure-python-function/main.tf line 51, in resource "azurerm_linux_function_app" "function_app":
│   51: resource "azurerm_linux_function_app" "function_app" {
│ 
│ publishing source (release.zip) to site App Service
│ (Subscription: "xxxx"
│ Resource Group Name: "xxx"
│ Site Name: "xxxxxx"): waiting for Zip Deployment to
│ complete
╵

But on subsequent applies, no changes are detected, the zip file is never uploaded again and code is still the old version

[github-actions]

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.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.