feat: reset password

[Mkassabov]

No description provided.

[Mkassabov]

this feels inherintly flawed since we store other things there (logs, miniflare data, etc)

[sam-goodwin]

That does look bad, yeah. State store is unfortunately legacy and really should be in its own folder under /.alchemy and not the root. Not sure how to achieve that for current users though.

[Mkassabov]

Honestly the more I think about it the more I think listStages is a mistake and this should only ever be allowed to run on 1 stage at a time.

[sam-goodwin]

Honestly the more I think about it the more I think listStages is a mistake and this should only ever be allowed to run on 1 stage at a time.

Oh yeah, why's that?

[Mkassabov]

Oh yeah, why's that?

• our state stores don't really seem to be designed around that most of them seem kind of hacky to access the stage
• there aren't a lot of usecases
  • lets say you have a project where every user gets their own stage; you can break somebody elses config
  • If you don't have a lot of stages (e.g. just production, staging, development) its not that hard to just run this 3 time
  • the only place I see this as being useful is per PR stages which don't last that long and aren't production so a key rotation there isn't really urgent (and can still be done with a script)
• this is an inherently a dangerous task because once you rotate a key you can't do much without re configuring your env to use the new key; so it should be treated with some sensitivity

bulk potentially dangerous action that has limited usecases and isn't well supported by our underlying state stores just smells off

[Mkassabov]

closing. this is just kind of not doable safely with the FS state store not being to identify all stages