Deletion of team results in resources that cannot be removed

[baughj]

What happened?

Our Pulumi Cloud environment has SCIM enabled and is using Entra as an SSO provider.

We have been using TeamStackPermission to grant access to a stack to a specific team.

However, if that team is removed or renamed by the SSO provider, or its assignment to Pulumi Cloud is revoked, both pulumi up and pulumi refresh will return error: Preview failed: failed to get team stack permission: failed to get team: 404 API error: Not Found: Team <teamname> not found. You effectively end up in an unrecoverable state that requires manual state deletion using pulumi stack delete of dozens / hundreds of permission resources which is not great.

Example

n/a

Output of pulumi about

CLI
Version      3.132.0
Go Version   go1.23.1
Go Compiler  gc

Plugins
KIND      NAME           VERSION
resource  aws            6.59.1
language  dotnet         unknown
resource  pulumiservice  0.26.3

Host
OS       ubuntu
Version  22.04
Arch     x86_64

This project is written in dotnet: executable='/usr/bin/dotnet' version='8.0.110'

Additional context

Pulumi cloud tied to Entra / Azure AD SSO, SCIM enabled.

if you are using SCIM / SSO, you may have teams that are not managed by the service provider (eg the person operating / running the Pulumi stack). These teams may be managed by entirely different groups in your company and are likely subject to change completely beyond your control.

I am not exactly sure what the behavior should be, however, I think it would be better that if a team does not exist, the permission depending on it is removed, rather than giving an error. I think at the very least pulumi refresh needs to be able to handle this state correctly to make it recoverable, since if the SSO provider has deleted a team, the team permissions have been deleted as well.

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

[komalali]

Thanks for opening the issue! I've recategorized this as an enhancement, since the provider is behaving as expected. We likely should change this resource to handle the case where the underlying team is deleted.