This message was deleted.
# generals
sparse-intern-71089
02/10/2023, 4:14 PMThis message was deleted.
c
creamy-agency-52831
02/10/2023, 4:16 PMHey 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 PMWe'll give it a shot to see if it reproduces with a small example
🙏 1
gray-school-37527
02/10/2023, 5:07 PM@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 PMHm - 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 PMIn our case, we had an unrelated error occur (problem configuring an ALB resource) which stopped the process before it could delete the V2 bucket.
gray-school-37527
02/10/2023, 5:13 PM"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
gray-school-37527
02/10/2023, 5:14 PMIn 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 PMThat 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 PMThe state before the update to V2 and after show a resource with the same resource id but different urns
gray-school-37527
02/10/2023, 5:18 PMBut 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 PMI 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 PMSeems 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 PMThanks 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 PMI'm guessing it's somehow related to this as well: https://www.pulumi.com/blog/announcing-v5.0.0-of-the-pulumi-aws-provider/#can-i-migrate-from-awss3bucket-to-awss3bucketv2
gray-school-37527
02/10/2023, 5:23 PMWhich is says will not re-create the bucket resource when moving from V1 to V2