https://pulumi.com logo
Title
g

gray-school-37527

02/10/2023, 4:14 PM
Created two buckets with the same URN (but different ids), and also caused a number of other resources to create resources with dupe URNs. Not sure if the Bucket switch back to aws.s3.Bucket is the root cause, but that's the thing that stands out.
c

creamy-agency-52831

02/10/2023, 4:16 PM
Hey Seth! Thanks for raising this here - this definitely doesn't sound like desired behavior, and I would love to see a full reproduction of the issue if you could provide one!
g

gray-school-37527

02/10/2023, 4:19 PM
We'll give it a shot to see if it reproduces with a small example
@creamy-agency-52831 We found the root cause and how to reproduce - it's a bit of an edge case we ran into. Create a bucket using aws.s3.BucketV2, run pulumi up, then update the script to try to create the same bucket using aws.s3.Bucket. Run up again. This will cause a new resource to be created with a different URN. Normally, the V2 bucket would then get removed. However, if an error occurs that prevents the script from completing, the V2 bucket never gets removed. Finally, try to run the script again using aws.s3.BucketV2 again. When this happens, the newly created V1 bucket's URN gets updated to match the left behind V2 bucket URN, resulting in a dupe URN.
c

creamy-agency-52831

02/10/2023, 5:11 PM
Hm - what kind of error would occur to prevent the script from completing? Also, it's a little unclear what the final step is there - so after the program has failed to remove the original V2 bucket, created the new V1 bucket, we then modify the code to attempt to create a V2 bucket again?
g

gray-school-37527

02/10/2023, 5:12 PM
In our case, we had an unrelated error occur (problem configuring an ALB resource) which stopped the process before it could delete the V2 bucket.
"so after the program has failed to remove the original V2 bucket, created the new V1 bucket, we then modify the code to attempt to create a V2 bucket again?" -- Correct
In our scenario, we accidently deployed an old version of our pulumi script to dev (went back to using V1), ran into the scenario described above, and then try deploying the new version of our pulumi script (which used V2)
c

creamy-agency-52831

02/10/2023, 5:15 PM
That should result in a new V2 bucket being created - is that the resource whose URN is updated to match the orphaned V2 bucket? I'd be shocked if the V1 bucket's URN were updated, as that's not an operation we generally ever do.
g

gray-school-37527

02/10/2023, 5:17 PM
The state before the update to V2 and after show a resource with the same resource id but different urns
But either way, it's ending up in the state with two resources with the same urn in the state if you follow the steps above.
c

creamy-agency-52831

02/10/2023, 5:19 PM
I would expect some weirdness if a pulumi program panics mid-run, which would likely necessitate some amount of manual state wrangling. It does seem worthwhile to open an issue in pulumi/pulumi with the exact repro you've mentioned above!
g

gray-school-37527

02/10/2023, 5:20 PM
Seems like an edge case for sure, as a result of the error mid-deploy. Thanks for reviewing.
c

creamy-agency-52831

02/10/2023, 5:21 PM
Thanks for your patience talking through it with me 🙂 It would definitely be ideal if we could gracefully recover from a state like this, but since this is likely a set of steps which happen somewhere deep in the engine, it'll take a bit of digging to determine if that's even possible. I expect folks on the engine side of things will have a much more clear set of answers for you.
g

gray-school-37527

02/10/2023, 5:22 PM
Which is says will not re-create the bucket resource when moving from V1 to V2