Subnet replaced during upgrade under PRC

[VenelinMartinov]

Describe what happened

The following example causes a replacement without any changes to the program in the Subnet resource when upgrading from anything before 5.79 to anything after 5.80 under PRC.

This is not the case under non-PRC. The cause is the addition of a new parameter default_outbound_access_enabled in TF with the following schema:

"default_outbound_access_enabled": {
	Type:     pluginsdk.TypeBool,
	Default:  true,
	Optional: true,
	ForceNew: true,
},

When the provider runs an update with the parameter not present in the state, it forces a replacement.

Unfortunately this is the truthful behaviour in TF but only under -refresh=false:

provider "azurerm" {
  features {}
  version = "3.85.0" // upgrade to 3.115.0
}

resource "azurerm_resource_group" "exampleResourceGroup" {
  name     = "exampleResourceGroup"
  location = "East US"
}

resource "azurerm_virtual_network" "exampleVirtualNetwork" {
  name                = "exampleVirtualNetwork"
  address_space       = ["10.0.0.0/16"]
  location            = azurerm_resource_group.exampleResourceGroup.location
  resource_group_name = azurerm_resource_group.exampleResourceGroup.name
}

resource "azurerm_subnet" "exampleSubnet" {
  name                 = "exampleSubnet"
  resource_group_name  = azurerm_resource_group.exampleResourceGroup.name
  virtual_network_name = azurerm_virtual_network.exampleVirtualNetwork.name
  address_prefixes     = ["10.0.2.0/24"]
}

Sample program

name: network
runtime: yaml
resources:
  exampleResourceGroup:
    type: azure:core:ResourceGroup
    properties:
      location: East US

  exampleVirtualNetwork:
    type: azure:network:VirtualNetwork
    properties:
      addressSpaces:
        - 10.0.0.0/16
      location: ${exampleResourceGroup.location}
      resourceGroupName: ${exampleResourceGroup.name}

  exampleSubnet:
    type: azure:network:Subnet
    properties:
      resourceGroupName: ${exampleResourceGroup.name}
      virtualNetworkName: ${exampleVirtualNetwork.name}
      addressPrefixes:
        - 10.0.2.0/24

Log output

No response

Affected Resource(s)

No response

Output of pulumi about

.

Additional context

No response

Contributing

Vote on this issue by adding a 👍 reaction.
To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).

[VenelinMartinov]

We could solve this with a TransformFromState, similar to #2150

This could lead to inaccurate state but the parameter does have a default and if the user really cared about that state, they'd refresh it.

This would also maintain the behaviour under non-PRC.

[pulumi-bot]

This issue has been addressed in PR #2306 and shipped in release v5.88.0.