like, seriously…>? app.pulumi.com blindly allowed this to happen some how and now I don’t know how to get back the old stack version on thei hosted version. S3 would be easy I’d just go to previous object versions

I was able to manually export the stack and remove the duplicates — but this seems like a problem if the stack is removed from the UI, but after renaming it, pulumi (on the app/hosted side) grabs an old stack and merges them or whatever it’s doing

hmm now I’m getting weird panics

guess I am going to have to manually remove all the resources marked for deletion,k and manually reimport them.. what a mess

I’d definitely be interested in making sure we don’t allow renames that end up in the state you described.

Separately, if you’re using app.pulumi.com, for a stack, you can always go to the activity tab, open the details for a previous update, and you’ll see a Download button on the right that allows you to download that particular state.

but the problem is, once it’s renamed the “old stack” disappears from both the UI and CLI so I can’t even pull a previous version of the old name

I used to have a stack called

test

and I renamed

test-v2

-> test after previously removing the

test

stack from the same project.

I feel like Pulumi doesn’t check for this edge-case, and merged my stack state with an old junk version of

test

lying around on the app’s filestore

that’s how I have all these duplicates

like I said, in S3 land, I would just revert to the previous stack but alas I cannot since

test-v2

got obliterated from the UI and the usable CI aftter performing the rename, so I can’t even force re-import a version of

test-v2

state back in even if I wanted to

bad edge case is bad @faint-table-42725 😛

I should have known better and not attempted to rename that back to a previously deleted stack 🤷

now I have a 2 hour shitshow of manually re-importing shit since I can’t get access to the old version easily

I’ll file a bug on our end to investigate the potential merge behavior. Just to clarify for repro purposes, there used to be a

test

stack, which you deleted. Then, you had a new stack called

test-v2

which you then renamed to

test

and then bad things happened?

so I was like wut?

I think I’m past that point. Out of 88 resources I only had to manually contend with about 6 or 7 of them (delete from stack forcefully, reimport with pulumi import manually).

also what’s super interesting the ONLY resources that got duped some how were of this type:

not sure if that helps pinpoint this

er

aws provider — not even sure why that would matter, but it didn’t seem to dupe a lot of the others

if I do get some time I might try replicating this in a lab set up

It’s just hard for me to reproduce, beyond the action part, since I am not hosting app.pulumi.com 😄

for future mental note though, I will definitely be doing a

pulumi export

before I rename any stacks on app.puluim.com just so I have a copy in case 😉

makes me wonder if the tool should do this too

this was typical terraform behavor when doing things like moving things around in the state, it wold dump a tfstate backup file even if the remote state provider was S3, terraform cloud, etc, just for safety.

that way if things got weird, I could still force re-import the “dumped state” back into the destination renamed stack

Oh yea I commented — might be good to also have

pulumi stack rm

do the same.

I know there’s a confirmation, if a user uses -y or --force, .. well… I mean, yeah let’s blame them for being dumb, but it’s a good idea to spit that exported state out locally and let them decide to clean it up… and maybe have a flag to override this I dunno. I’m not in the camp of protecting people from themselves all the time, but states are just so sensitive, important and integral to the operation of pulumi, that having a backup of a backup and extra safety checks for this seems fine to me.

I break down stacks into smaller components on purpose because of this (lessons learned from terraform), but not everyone does or can and some stacks can get big, and fingers get twitchy and before you know it… user just killed all their infra state

and app.pulumi.com is not very forgiving about letting me to see a deleted stack

🙂