frontdoor - read context deadline exceeded

[timja]

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

Affected Resource(s)

• azurerm_frontdoor

Terraform Configuration Files

https://github.com/hmcts/azure-platform-terraform/blob/master/modules/azure-landing-zone/frontdoor.tf#L5
https://github.com/hmcts/azure-platform-terraform/blob/master/environments/ithc/ithc.tfvars#L26

Debug Output

error: retrieving Front Door Frontend Endpoint "sscs-cor" (Resource Group "lz-perftest-rg"): frontdoor.FrontendEndpointsClient#Get: Failure sending request: StatusCode=0 -- Original Error: context deadline exceeded

Expected Behavior

It shouldn't timeout

Actual Behavior

It timed out

Steps to Reproduce

1. terraform apply

Important Factoids

We have quite a few frontend endpoints

Seems to be caused by:
#7485

@WodansSon @tombuildsstuff

References

• #0000

[darrenk13]

I have been using Front Door with custom domains and found that I needed to increase the read timeout of the resource to get it to complete being created successfully. It looks like Azure or Terraform goes through the frontends serially when they are defined as part of the Front Door resource. Domain validation was taking 5-10 minutes each for me.

Have you tried using the new resource azurerm_frontdoor_custom_https_configuration ? The Terraform docs say that using that resource type allows the frontends with custom https settinsgs to be created and updated in parallel.

[timja]

@darrenk13 we wrote that resource and were updating to the latest provider version before changing over to using that and hit this.

Will give it a try doing it in one go as that might fix it

But this is definitely a regression as this worked on the old provider versions

[ignatz42]

To workaround this regression, we have explicitly set the azurerm_frontdoor resouce read timeout to '6h' like the create, update, and delete timeouts. In our case, the Front Door resource is being updated and the modification takes almost 2 hours to complete. Without the timeout set, the apply operation fails after ~10 minutes.

[timja]

cc @tombuildsstuff

[tombuildsstuff]

@timja I believe this has been fixed in 2.24/2.25 - can you take a look?

[timja]

Read timeout hasn't been changed https://github.com/terraform-providers/terraform-provider-azurerm/blob/master/azurerm/internal/services/frontdoor/frontdoor_resource.go#L58

but was there a bug fix around here @tombuildsstuff ?

I can't see a specific fix but there are changes to the resource in 2.24

[tombuildsstuff]

@timja the read timeout is correct (at 5 minutes) - the issue (IIRC fixed as a part of #8146) was that the read timeout was unintentionally used inside a create/update which has been fixed - so this should be resolved

[timja]

fyi @naikajah @luigibk if you have time to take a look.

(I'm going on holiday now for a week).

Thanks for your response!

[tombuildsstuff]

@timja enjoy your holiday :)

[ignatz42]

Thanks for the quick response. Initially, I was using version 2.23 of the provider. I upgraded to version 2.25 and my long running update has made it to the 1 hour mark (and still going) with the default timeouts. This is closed from my perspective. Thanks again for the help.

[tombuildsstuff]

Closing since as per @ignatz42's comment this is confirmed resolved.

[ghost]

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 feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 hashibot-feedback@hashicorp.com. Thanks!