Breaking change in azuread.ServicePrincipalPassword

[scottmack111]

Describe what happened

I've been using azuread.ServicePrincipal in conjunction with azuread.ServicePrincipalPassword. Im currently running pulumi-azuread v5.53.4 and attempting to upgrade to v6.0.1. When running my deployments now I get the following error

error: azuread:index/servicePrincipalPassword:ServicePrincipalPassword resource 'xxxxxxx' has a problem: parsing "6dca80f1-fa7e-4ba4-bc8c-7e6219b506c2": parsing the ServicePrincipal ID: the number of segments didn't match

Expected a ServicePrincipal ID that matched (containing 2 segments):

> /servicePrincipals/servicePrincipalId

However this value was provided (which was parsed into 0 segments):

> 6dca80f1-fa7e-4ba4-bc8c-7e6219b506c2

The following Segments are expected:

* Segment 0 - this should be the literal value "servicePrincipals"
* Segment 1 - this should be the user specified value for this servicePrincipalId [for example "servicePrincipalId"]

Sample program

const servicePrincipal = new azuread.ServicePrincipal(name, {
    clientId: app.clientId
});

const servicePrincipalPassword = new azuread.ServicePrincipalPassword(name, {
    servicePrincipalId: servicePrincipal.id,
    endDate: passwordExpiryDate,
});

Log output

error: azuread:index/servicePrincipalPassword:ServicePrincipalPassword resource 'xxxxxxx' has a problem: parsing "6dca80f1-fa7e-4ba4-bc8c-7e6219b506c2": parsing the ServicePrincipal ID: the number of segments didn't match

Expected a ServicePrincipal ID that matched (containing 2 segments):

> /servicePrincipals/servicePrincipalId

However this value was provided (which was parsed into 0 segments):

> 6dca80f1-fa7e-4ba4-bc8c-7e6219b506c2

The following Segments are expected:

* Segment 0 - this should be the literal value "servicePrincipals"
* Segment 1 - this should be the user specified value for this servicePrincipalId [for example "servicePrincipalId"]

Affected Resource(s)

azuread.ServicePrincipalPassword

Output of pulumi about

CLI
Version 3.139.0
Go Version go1.23.3
Go Compiler gc

Plugins
KIND NAME VERSION
resource azure 6.9.0
resource azuread 6.0.1
resource kubernetes 4.18.3
language nodejs unknown
resource random 4.16.7

Host
OS Microsoft Windows 11 Pro
Version 10.0.22631 Build 22631
Arch x86_64

Additional context

I can work around it using

const servicePrincipal = new azuread.ServicePrincipal(name, {
    clientId: app.clientId
});

const servicePrincipalId = pulumi.interpolate`/servicePrincipals/${servicePrincipal.id}`;

const servicePrincipalPassword = new azuread.ServicePrincipalPassword(name, {
    servicePrincipalId: servicePrincipalId,
    endDate: passwordExpiryDate,
});

However when doing this it now wants to replace my SP Password resource

        "diffReasons": [
            "servicePrincipalId"
        ],
        "replaceReasons": [
            "servicePrincipalId"
        ],
        "detailedDiff": {
            "servicePrincipalId": {
                "kind": "update-replace",
                "inputDiff": false
            }
        }

Because servicePrincipalId is changing from "GUID" to "/servicePrincipals/GUID"

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

[danielrbradley]

Hi @scottmack111 this seems to be related to a breaking change in the upstream provider which wasn't documented in the release notes.

The ServicePricipal id property changed to include the prefix /servicePrincipals/ and updated the parsing of any servicePrincipalId properties to require the prefix. There is a migration which is applied within the provider, however, this migration is not currently run by pulumi within the preview phase (see pulumi/pulumi-terraform-bridge#2676).

The workaround for the time being is, when upgrading the provider (ideally with no other changes), perform the update with the --skip-preview. Once the state is updated to the new version of the provider, this issue will then go away. You can also try running with the --expect-no-changes option which should work here as there should be no actual changes once the migration has run, but will prevent any updates, deletes or creates to be run by the engine.

Separately, I've raised an issue in the bridge to address the problem long-term.