Make Frontdoor compatible with XSkipDetailedDiffForChanges

[t0yv0]

Hello!

• Vote on this issue by adding a 👍 reaction
• If you want to implement this feature, comment to let us know (we'll work with you on design, scheduling, etc.)

Issue details

The Frontdoor resource needs tweaking to operate correctly with XSkipDetailedDiffForChanges.

Context: bridge is introducing a change to the diffing algorithm that is currently flagged under
XSkipDetailedDiffForChanges but is on the fast track to become turned on unconditionally as it
solves important issues for GCP and AWS provider. This change was introduced in:
pulumi/pulumi-terraform-bridge#1502

When pre-testing this change through Azure tests, TestAccFrontoor started failing. It is expected
that after a successful pulumi up, the subsequent pulumi preview generates a no-changes plan.
With XSkipDetailedDiffForChanges it started to generate an Update plan instead, based on these
attributes:

     CHANGING FROM DIFF_NONE to DIFF_SOME
    ~ "backend_pool_settings.#" => {1 0 false false <nil> false false 0}
    ~ "backend_pool_settings.0.backend_pools_send_receive_timeout_seconds" => {0 60 false false <nil> false false 0}

Investigating this further, the root cause was discovered. The
backendPoolsSendReceiveTimeoutSeconds setting is advertised as defaulting to 60 in the docs, but
this default value is not exposed through normal metadata in the upstream provider but enforced at
runtime. The code references here are:

• https://github.com/hashicorp/terraform-provider-azurerm/blob/master/internal/services/frontdoor/frontdoor_resource.go#L1034
• https://github.com/hashicorp/terraform-provider-azurerm/blob/master/internal/services/frontdoor/frontdoor_resource.go#L272

It appears that this default value is applied on the read path. Since Pulumi differs from TF in not
automatically applying a Read upon every update, the initial pulumi up deployment fails to apply
the default, while the subsequent deployment does apply the default.

A possible mitigation here would be to lift the 60 default to the regular defaulting mechanism,
possibly by populating SchemaInfo.Default override for this property, which should make Pulumi apply
this default consistently and avoid unexpected plans.

Affected area/feature

[VenelinMartinov]

Looks like this also happens in terraform:

terraform {
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "3.102.0"
    }
  }
}

# Configure the Microsoft Azure Provider
provider "azurerm" {
  features {}
}

resource "azurerm_resource_group" "example" {
  name     = "resourceGroup"
  location = "West Europe"
}

resource "azurerm_frontdoor" "example" {
  name                = "example476"
  resource_group_name = azurerm_resource_group.example.name

  routing_rule {
    name               = "rule1"
    accepted_protocols = ["Http", "Https"]
    patterns_to_match  = ["/*"]
    frontend_endpoints = ["frontEndEndpoint1"]

    forwarding_configuration {
      forwarding_protocol = "MatchRequest"
      backend_pool_name   = "exampleBackendBing"
    }
  }

  backend_pool_load_balancing {
    name = "exampleLoadBalancingSettings1"
  }

  backend_pool_health_probe {
    name         = "exampleHealthProbeSetting1"
    protocol     = "Https"
    probe_method = "HEAD"
  }

  backend_pool {
    name = "exampleBackendBing"
    backend {
      host_header = "www.bing.com"
      address     = "www.bing.com"
      http_port   = 80
      https_port  = 443
    }

    load_balancing_name = "exampleLoadBalancingSettings1"
    health_probe_name   = "exampleHealthProbeSetting1"
  }

  frontend_endpoint {
    name      = "frontEndEndpoint1"
    host_name = "example476.azurefd.net"
  }
}

I wonder if setting the property as computed would fix this, as the provider is giving a value for a non-computed property here.

[VenelinMartinov]

Opened hashicorp/terraform-provider-azurerm#25911 upstream, will try to patch it on our side and ignore in the test if not.