Hi there! I just got burned on something that was entirely my own fault, but I feel like Pulumi could have handled better. Long story short, in a single

pulumi up

I tried to both 1. rename a resource using

aliases

2. make a change to that same resource which caused it to be

replace

d This failed with

pending_operations

in the state file because I ended up with two different resources with the same alias at the same time. I guess the GCP and Kubernetes providers perform a

replace

by first creating the new resource and then deleting the old one? If so, I believe this will hit any resource which has any

aliases

defined, i.e., you don’t necessarily have to rename the resource at the same time as replacing it. I tried reproducing it in a local stack using the

@pulumi/random

provider, but I think that one replaces resources by deleting the old resource before creating the new one. For what it’s worth, I managed to make Pulumi show me this kind-of-strange diff:

pulumi preview
Previewing update (dev):
     Type                            Name                           Plan        Info
     pulumi:pulumi:Stack             pulumi-alias-replace-test-dev
 +-  ├─ random:index:RandomPassword  something_else                 replace     [diff: ~length]
 +-  └─ random:index:RandomPassword  pw                             replace

Resources:
    +-1 to replace
    1 unchanged

Here I’ve renamed the resource

pw

to

something_else

, added an alias, and at the same time changed the

length

of the RandomPassword which requires a

replace

operation. Does this ring a bell with anyone and/or is it worth a GitHub issue even though I haven’t been able to reproduce it (yet)?

AFAIK Pulumi will always do a

create, then delete

for a

replace

action unless you specify

deleteBeforeReplace: true

in the

ResourceOptions

for any given resource. Meaning the order this takes place is not determined by the provider. Unfortunately I can't speak to the specific issue with your alias change so hopefully someone else will chime in

Huh, that’s weird that it failed for both a GCP service account and a Kubernetes secret but not for a RandomPassword then. Maybe my hypothesis is completely off 😄

The difference might just a side effect of the fact that RandomPassword isn’t actually provisioning any cloud infrastructure?

Possibly. Not sure why it should result in two different resources with the same alias though, if it’s guaranteed to delete the old resource before creating the new one