# Description
In
30f59eb30a,
we made sure that we
don't delete multiple resources, when a user is prompted to choose
between multiple resources with the same URN.
If there are non-unique URNs, we currently assume that we can just go
ahead and delete it, as there's still another resource that will
fulfill the requirements.
However that is not true if the dependent is a provider. Providers
are identified by a {URN, ID} tuple. Therefore even though after the
deletion of a provider with a specific URN there's still another one
with the same URN left, this is not good enough to fulfill the
dependency requirements.
If we don't have a unique URN, check again to make sure there's no
provider dependency on the condemned resource. If there is one, we
either error out, or delete the dependencies depending on the options
passed in.
Note that I haven't managed to reproduce this by just issuing pulumi
commands, but I did by editing the state in a way to reproduce the same
issue.
One unanswered question for me is how the deleted cluster in the
original issue ended up lingering in the state. While this PR fixes the
panic, and will make it easier for the user to actually delete the
cluster from the state (it's going to suggest `--target-dependents`
which will do the right thing), it doesn't address that bit.
Fixes https://github.com/pulumi/pulumi/issues/15166
## Checklist
- [x] I have run `make tidy` to update any new dependencies
- [x] I have run `make lint` to verify my code passes the lint check
- [x] I have formatted my code using `gofumpt`
<!--- Please provide details if the checkbox below is to be left
unchecked. -->
- [x] I have added tests that prove my fix is effective or that my
feature works
<!---
User-facing changes require a CHANGELOG entry.
-->
- [x] I have run `make changelog` and committed the
`changelog/pending/<file>` documenting my change
<!--
If the change(s) in this PR is a modification of an existing call to the
Pulumi Cloud,
then the service should honor older versions of the CLI where this
change would not exist.
You must then bump the API version in
/pkg/backend/httpstate/client/api.go, as well as add
it to the service.
-->
- [ ] Yes, there are changes in this PR that warrants bumping the Pulumi
Cloud API version
<!-- @Pulumi employees: If yes, you must submit corresponding changes in
the service repo. -->
---------
Co-authored-by: Fraser Waters <fraser@pulumi.com>
6f41d715d9