Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Creating azurerm_windows_web_app_slot with virtual_network_subnet_id specified results in Internal server error (500) #24618

Closed
1 task done
UntiIted opened this issue Jan 24, 2024 · 29 comments · Fixed by #25634
Labels
service/app-service upstream/microsoft/blocking-api-issue This label is applicable when there is a bug on the Azure API that is blocking. v/3.x
Milestone

Comments

@UntiIted
Copy link

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.7.0

AzureRM Provider Version

3.88.0

Affected Resource(s)/Data Source(s)

azurerm_windows_web_app_slot

Terraform Configuration Files

resource "azurerm_windows_web_app_slot" "this" {
  name           = "test"
  app_service_id = "***"
  virtual_network_subnet_id = "***"

  site_config {
  }
}

Debug Output/Panic Output

╷
│ Error: creating Windows Web App Slot: (Slot Name "***" / Site Name "***" / Resource Group "***"): web.AppsClient#CreateOrUpdateSlot: Failure sending request: StatusCode=500 -- Original Error: Code="Failed" Message="The async operation failed." AdditionalInfo=[{"Message":"An error has occurred."}]
│
│   with azurerm_windows_web_app_slot.this,
│   on main.tf line 144, in resource "azurerm_windows_web_app_slot" "this":
│  144: resource "azurerm_windows_web_app_slot" "this" {
│
│ creating Windows Web App Slot: (Slot Name "***" / Site Name "***" / Resource Group "***"): web.AppsClient#CreateOrUpdateSlot: Failure sending request: StatusCode=500 -- Original Error: Code="Failed" Message="The async operation failed." AdditionalInfo=[{"Message":"An error has occurred."}]
╵

Expected Behaviour

A web app slot is created with virtual network integration

Actual Behaviour

Error 500 is thrown, web app slot is not created.

Steps to Reproduce

Deploy a windows web app slot with subnet specified, make sure to use v3.88.0. Issue does not occur on v3.87.0 and earlier.

Important Factoids

No response

References

No response

@UntiIted
Copy link
Author

Important to note: deploying an app through REST API with vnet integration fails with 500 as well.
Deployment was based on reference here: https://learn.microsoft.com/en-us/rest/api/appservice/web-apps/create-or-update-slot?view=rest-appservice-2022-03-01.

@shreedharsed
Copy link

We are also facing same issue with azurerm_windows_function_app_slot.

@carbage
Copy link

carbage commented Jan 25, 2024

I would also like to report that this issue is present when using the virtual_network_subnet_id setting on azurerm_windows_function_app_slot resources. Removal mitigates the issue.

I'd also like to add that using azurerm_app_service_slot_virtual_network_swift_connection appears to be a valid workaround

@vipul2996
Copy link

we were also facing same issue. we commented out "virtual_network_subnet_id " in the slot and then ran terraform apply which completed then we again uncommented "virtual_network_subnet_id " and second run terraform completed with subnet id and updated slot.

@VazquezAgustin
Copy link

VazquezAgustin commented Jan 30, 2024

There was an schema update for the resource azurerm_service_plan so it's not possible to roll back to 3.87 in order to workaround the issue without removing and importing the resource from the state

@birenshah2
Copy link

We are getting the same error with both 3.88.0 and 3.89.0. After enabling trace logging, the only difference we can see between the successful 3.87.0 payload and the 3.89.0 payload is that the successful one is also passing the serverFarmId (i.e. the app service plan) whereas that ONE line is missing in the payload using 3.89.0.

@birenshah2
Copy link

Just tried 3.90.0 and am still getting a 500 error.

@VazquezAgustin
Copy link

Sharing the script to reproduce the bug. I can confirm that @birenshah2 comment is accurate.
If serverFarmId is removed from the below script, you will get a 500.

$subscriptionId = ""
$resourceGroupName = ""
$webAppName = ""
$slotName = ""
$apiVersion = ""
$vnetName = ""

$accessToken = (az account get-access-token --resource https://management.azure.com | ConvertFrom-Json).accessToken

$endpointUrl = "https://management.azure.com/subscriptions/$subscriptionId/resourceGroups/$resourceGroupName/providers/Microsoft.Web/sites/$webAppName/slots/$($slotName)?api-version=2022-03-01"

$headers = @{
    "Authorization" = "Bearer $accessToken"
    "Content-Type" = "application/json"
}

$requestBody = @{
    "location" = "Central US"
    "properties" = @{
        # Add properties as needed
        "serverFarmId" = "<farm id>"
        "virtualNetworkSubnetId" = "<subnetid>"
    }
} | ConvertTo-Json

$response = $null

try {
    $request = [System.Net.HttpWebRequest]::Create($endpointUrl)
    $request.Method = "PUT"
    $request.Headers.Add("Authorization", "Bearer $accessToken")
    $request.ContentType = "application/json"

    if ($requestBody) {
        $streamWriter = [System.IO.StreamWriter] $request.GetRequestStream()
        $streamWriter.Write($requestBody)
        $streamWriter.Flush()
        $streamWriter.Close()
    }

    $webResponse = $request.GetResponse()
    $streamReader = [System.IO.StreamReader] $webResponse.GetResponseStream()
    $response = $streamReader.ReadToEnd()

    if ($webResponse.StatusCode -eq [System.Net.HttpStatusCode]::OK) {
        Write-Host "Slot created successfully!"
    } else {
        Write-Host "Failed to create slot. Status code: $($webResponse.StatusCode)"
        Write-Host "Response: $response"
    }

    $webResponse.Close()
    $streamReader.Close()
} catch {
    $errorMessage = $_.Exception.Message
    Write-Host "Error message: $errorMessage"
    if ($_.Exception.Response) {
        $errorResponse = (New-Object System.IO.StreamReader($_.Exception.Response.GetResponseStream())).ReadToEnd()
        Write-Host "Error response: $errorResponse"
    }
}

@bdorplatt
Copy link

bdorplatt commented Feb 8, 2024

Same issue here with virtual_network_subnet_id in the resource azurerm_windows_function_app_slot : #24727

@rcskosir
Copy link
Contributor

This should be resolved with v3.91, specifically this part of the release: commonids.ParseAppServiceEnvironmentIDInsensitively(). As such, I am going to mark this issue as closed. If after upgrading that is not the case, please provide additional information including the version in which you are still experiencing this issue, thanks!

@VazquezAgustin
Copy link

I am still facing the issue with the azurerm_windows_web_app_slot, I did not test the function app slot

Slot Name: "blue"): performing CreateOrUpdateSlot: unexpected status 500 with response: {"Message":"An error has occurred."}

azurerm provider version 3.91.0
terraform version 1.4.5

Can we re open it?

@birenshah2
Copy link

Yes, I just tried it out with 3.91.0 and got the same as VasquezAgustin above.

azurerm provider version 3.91.0
terraform version 1.7.3

I will say I had a case open with Microsoft Azure Support on this matter, and they have confirmed that there is a networking related issue on their side that is causing the issue. They have indicated that it should get fixed in version 102.x.x.x of App Service, which might be another couple weeks. You can view the version by checking the Environment tab on the SCM site for any App Service.

@rcskosir
Copy link
Contributor

Thank you @VazquezAgustin and @birenshah2 for the updates! I will go ahead and reopen it and label it with upstream/microsoft to indicate that networking related issue on their side that it should get fixed in version 102.x.x.x of App Service.

@rcskosir rcskosir reopened this Feb 15, 2024
@rcskosir rcskosir added the upstream/microsoft/blocking-api-issue This label is applicable when there is a bug on the Azure API that is blocking. label Feb 15, 2024
@jhernandez-vendavo
Copy link

The issue persists; simply reporting for the record.

Terraform Version: v1.7.4
Platform: darwin_arm64
Provider: registry.terraform.io/hashicorp/azurerm v3.94.0

@Dmitrii034
Copy link

We've also filed a support ticket for Microsoft regarding this issue. Their investigation concluded that prior to azureRM version 3.88.0 the provider automatically filled out the serverFarmId property. After that version, the provider no longer fills the serverFarmId property and it is left out of the submitted template. Could you please look into how this property is handled?

@saveler
Copy link

saveler commented Mar 27, 2024

Hello @rcskosir

I made some investigations:

  1. the problem started after 3.88.0 release
  2. there was only one change related to appservices\functions dependencies: azurerm_service_plan - update to use hashicorp/go-azure-sdk #24483; according to the change, now serverFarmId is sent in payload only if service service_plan_id is specified, but when we try to specify it, we get the following error: Error: service_plan_idshould only be specified when it differs from theservice_plan_id of the associated Web App

I believe that I'm right that exactly this change is a root cause of our problems. There should be a reason why it was implemented, but I still can't understand, why the change was implemented for App Service Windows slot only, but Linux slot, Function slots were kept without the change.

I will add @jackofallops to this conversation, maybe he will be able to help us to solve the issue!

Thank you in advance!

@websolut
Copy link

websolut commented Apr 2, 2024

We experience the same error with a windows function app slot since moving to TF azurerm provider 91.

@bubbletroubles
Copy link
Contributor

@rcskosir this has been tagged as upstream/Microsoft however it seems that there is no upstream issue. 

Isn't the fix here for the Terraform provider to supply the serverFarmId property?

@dsiperek-vendavo
Copy link

Any updates on a fix for this? We are also running into this issue and can't downgrade below 3.87

@Apokalypt
Copy link
Contributor

Apokalypt commented Apr 16, 2024

Apparently, the Azure API has been updated and the error is now clearer (409 instead of 500) :
image

@websolut
Copy link

We noticed that not providing virtual_network_subnet_id when you create the slot, we can at least run TF to create the slot. Then we add this parameter and run TF again. It is a very painstaking exercise but seems it works.

@birenshah2
Copy link

@Apokalypt @websolut I'm confused... in response to both of your comments, I am already passing in an app_service_id (which in turn lives in an app service plan) and a virtual_network_subnet_id. The documentation for the resource says:

service_plan_id - (Optional) The ID of the Service Plan in which to run this slot. If not specified the same Service Plan as the Windows Web App will be used.

So I think I'm running this as intended and as suggested by the error/warning above, no? Any other thoughts on this?

@Apokalypt
Copy link
Contributor

@Apokalypt @websolut I'm confused... in response to both of your comments, I am already passing in an app_service_id (which in turn lives in an app service plan) and a virtual_network_subnet_id. The documentation for the resource says:

service_plan_id - (Optional) The ID of the Service Plan in which to run this slot. If not specified the same Service Plan as the Windows Web App will be used.

So I think I'm running this as intended and as suggested by the error/warning above, no? Any other thoughts on this?

@birenshah2 You are correctly using the service but right now there is a bug, I'm currently developing a fix and will create a PR for that in few mins.
To add details, the property "serverFarmId" is needed by the API when you try to set a "virtualNetworkSubnetId" but, since 3.88.0 if my memory is good, terraform provide this value ONLY when the value is different from that of the parent webapp/function (cf code)

@birenshah2
Copy link

@Apokalypt @websolut I'm confused... in response to both of your comments, I am already passing in an app_service_id (which in turn lives in an app service plan) and a virtual_network_subnet_id. The documentation for the resource says:

service_plan_id - (Optional) The ID of the Service Plan in which to run this slot. If not specified the same Service Plan as the Windows Web App will be used.

So I think I'm running this as intended and as suggested by the error/warning above, no? Any other thoughts on this?

@birenshah2 You are correctly using the service but right now there is a bug, I'm currently developing a fix and will create a PR for that in few mins. To add details, the property "serverFarmId" is needed by the API when you try to set a "virtualNetworkSubnetId" but, since 3.88.0 if my memory is good, terraform provide this value ONLY when the value is different from that of the parent webapp/function (cf code)

Sounds good! Thank you!!

@jvlake
Copy link

jvlake commented Apr 21, 2024

Hi folks, please vote on the PR, this has been broken for months.

#25634

@tdkeeley
Copy link

tdkeeley commented May 9, 2024

We've also filed a support ticket for Microsoft regarding this issue. Their investigation concluded that prior to azureRM version 3.88.0 the provider automatically filled out the serverFarmId property. After that version, the provider no longer fills the serverFarmId property and it is left out of the submitted template. Could you please look into how this property is handled?

Hi @Dmitrii034 if you have any details about the investigation, maybe we can get some traction over on the PR. There is some hesitation without confirming with Microsoft, which sounds like you already did.

#25634 (comment)

@Dmitrii034
Copy link

@tdkeeley Sorry, we did not get much else from that investigation. They recommended us to specify the parameter ourselves, but it is currently not possible due to validation on the provider. The only other thing of note is that they told us that they would make the resulting error clearer. This is probably why the new error now states that the parameter is missing. Not sure what is the reason for the current delay.

@github-actions github-actions bot added this to the v3.105.0 milestone May 21, 2024
Copy link

This functionality has been released in v3.105.0 of the Terraform Provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading.

For further feature requests or bug reports with this functionality, please create a new GitHub issue following the template. Thank you!

Copy link

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.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jun 24, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
service/app-service upstream/microsoft/blocking-api-issue This label is applicable when there is a bug on the Azure API that is blocking. v/3.x
Projects
None yet