Upgrading from v4 to v5 causes storage accounts to be recreated

[barclayadam]

What happened?

Upgrading from 4.37.0 to ^5.60.0 has caused all storage accounts to require a replacement. I can see nothing that has changed in the output. The only diff in source is replacing allowPublicAccess with allowNestedItemsToBePublic as required.

The complete diff output in Pulumi web app shows no changes:

  pulumi:pulumi:Stack: (same)
    [urn=urn:pulumi:uat-deploy-global::download-storage::pulumi:pulumi:Stack::download-storage-uat-deploy-global]
    > pulumi:pulumi:StackReference: (read)
        [id=symprex/cloudflare/uat-deploy-global]
        [urn=urn:pulumi:uat-deploy-global::download-storage::pulumi:pulumi:StackReference::symprex/cloudflare/uat-deploy-global]
        name: "symprex/cloudflare/uat-deploy-global"
error: unable to replace resource "urn:pulumi:uat-deploy-global::download-storage::azure:storage/account:Account::downloads-blob-store"
as it is currently marked for protection. To unprotect the resource, remove the `protect` flag from the resource in your Pulumi program and run `pulumi up`

I'm using the Automation API and have checked all events, and none of them contain any useful information on what it believes has changes

Example

new azure.storage.Account('downloads-blob-store', {
    resourceGroupName: globalResourceGroupName,
    name: downloadStoreName,

    accountTier: 'Standard',
    accountReplicationType: 'GZRS',

    enableHttpsTrafficOnly: true,

    accountKind: 'StorageV2',

    // Only change was this property, replacing deprecated allowBlobPublicAccess
    allowNestedItemsToBePublic: true,

    minTlsVersion: 'TLS1_2',

    accessTier: 'Hot',
}, {
    protect: true,
});

Output of pulumi about

CLI
Version 3.84.0
Go Version go1.21.1
Go Compiler gc

Plugins
NAME VERSION
azure 5.60.0
azure-native 2.24.0
azuread 5.46.0
cloudflare 5.0.0
docker 3.0.0
kubernetes 3.30.2
newrelic 5.10.0
nodejs unknown
random 4.0.0
tls 4.0.0

Host
OS Microsoft Windows 11 Pro
Version 10.0.22000 Build 22000
Arch x86_64

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

[iwahbe]

Hi @barclayadam. Thanks for reporting this issue. This looks like a bug on our end.

You might be able to work-around the bug by replacing allowBlobPublicAccess with allowNestedItemsToBePublic before upgrading the provider.

[barclayadam]

Hi @iwahbe. Do you mean by making a change in the state beforehand?

[iwahbe]

Yes.