The default answer for `supabase db reset --linked` should not be `Y`

[DanEEStar]

Is your feature request related to a problem? Please describe. I used the command supabase db reset --linked for the first time. I was suprised that the default answer is "Yes". In my opinion it should be "No" to at least prevent the reset when I accidently run the command and just pressed "enter".

Describe the solution you'd like The line 54 in reset.go

if shouldReset := utils.PromptYesNo("Confirm resetting the remote database?", true, os.Stdin); !shouldReset {

sould become

if shouldReset := utils.PromptYesNo("Confirm resetting the remote database?", false, os.Stdin); !shouldReset {

Describe alternatives you've considered No alternative

[sweatybridge]

Hmm I initially thought it's ok to default to Y because user passing in --linked flag is already expressing explicit intent to reset the remote database. And we are just confirming again.

But I'm happy to change it to your suggestion if it's safer to prevent accidental key press.

Also considering the behaviour on non-interactive consoles, we might want another flag --force to skip the promptly entirely.

[Ninjeneer]

I totally agree with this one, destructive actions should never be authorized by default

[tobiastornros]

Any plans to add --force or --yes to this command @sweatybridge? Trying to use it in github action to reset staging every night.

[sweatybridge]

You can pipe yes / no to cli via stdin. For eg.

yes | supabase db reset --linked

[tmountain]

We're piping yes now, but it does seem like a command-line arg is the right way. Also, this bit us out of the blue (staging environment broke on rebuild). Is there a better way to roll out breaking changes to core tools? Changing a command so that it runs interactively can definitely impact your users.

[sweatybridge]

Is there a better way to roll out breaking changes to core tools?

Perhaps the CLI can print the suggested replacement command on such breaking changes in the future. So at least it's more straightforward to fix any broken builds.

In this case, we had to fix it sooner than later to prevent more users from accidentally deleting prod data.