I can explain the problem a bit more, but I don’t think we settled on a desired behavior (it was before we had the handy issue template).

Context

coder server --dev is great for kicking the tires and everything is in-memory, which is a double edged sword. I could provision a bunch of infrastructure, and then shut down Coder with control c and that infrastructure will spin down.

The problem

However, I usually hit cntrl+c twice on terminal applications when I see it’s hanging a bit. Kind of like spamming alt f4 to close things. I am assuming others do this too. The issue is, when I do this, the “terraform delete” stops. Servers may stay up forever, and Coder will forget about them next time it runs so I’m paying a lot of $$$

Here’s one suggestion

Current behavior:

1. start coder with coder server --dev
2. create workspaces
3. hit cntrl c
4. hit cntrl c again quickly to speed up shutting down. however, all your test infrastructure will remain online :(

Desired behavior (suggestion):

1. start coder with coder server --dev
2. create workspaces
3. hit cntrl c
4. EDIT: hit cntrl c again
5. see dialog “Coder is shutting down your test workspaces so they don’t incur cloud costs. If you close Coder now, these servers will remain up. Are you sure? (y/n)”
6. Realize you want to shut down the workspaces, hit n and wait

Er, wait, do you want to see the dialog after the first CTRL+c? Or after a second CTRL+c?

I'm thinking we want the first CTRL+c to start a graceful shutdown. If you do nothing else, the program ends after this completes. When you hit the second CTRL+c, you're prompted. If you hit n you're back in the graceful shutdown state, if you hit y it immediately exits.

Additional CTRL+c while the prompt is up I guess is ignored? There is a slight danger that if we hang in that processing, you'll have to kill the process from another term.

Also, if graceful shutdown completes while the prompt is up, I think we exit, perhaps with a "nevermind, done" message.

Er, wait, do you want to see the dialog after the first CTRL+c? Or after a second CTRL+c?

Ah, you're absolutely right. I meant after the second!

Additional CTRL+c while the prompt is up I guess is ignored?
There is a slight danger that if we hang in that processing, you'll have to kill the process from another term.

That makes sense to me. I think cntrl d is like a fallback quit which Coder could still respect? Not sure what the typical behavior is for CLI apps, I believe I've seen different behaviors from different apps

So, I have something coded up, but it ends up being a little more complex that I would ideally like. The tricky bit is that we're outputting progress on the graceful shutdown to the terminal, which can end up clobbering the prompt. What I've done is implemented a little internal buffer that accepts the graceful shutdown text output, and just buffers it while the prompt is up, and then flushes it out when the prompt is done.

Branch is here: https://github.com/coder/coder/tree/spike_631_confirm_double_sigint

I'm concerned the extra usability is not quite worth the complexity I'd be introducing.

The other observation that I have is that what we have right now is the usual behavior for CLI apps: one CTRL+c starts a graceful shutdown, a second really terminates it. I do sympathize with the learned behavior that graceful shutdown doesn't matter in most cases, but do we really want to implement a different convention because we perceive the consequences of a missed graceful shutdown to be really severe?

@bpmct saw your thumbs up, but given that my last comment didn't take a definite position on what we should do, I'm not sure how to interpret your 👍 . So, let me lay out some specific options:

1. Close this issue without any changes, given the concerns expressed above
2. Test, review, and aim to merge the https://github.com/coder/coder/tree/spike_631_confirm_double_sigint branch
3. Ignore all CTRL+c after the first one (no prompt). If you want to interrupt graceful shutdown, you can do CTRL+\ (SIGQUIT). This avoids the awkwardness around text output and text prompt

Can you cast your support for one of these (or suggest additional alternatives)?

Ah my apologies. I thought this issue was being pushed to a future version and work was being stopped 🤦🏼

I feel as if 2 or 3 are better solutions. 3 seems like the best from a quality and UX perspective but I think @kylecarbs should have the final say, given the added complexity.

Option 3 is low complexity. It's really only 2 that is wooly in that way.

Ah ok, 3 seems the safest to me across the board.

The downside to Option 3 is that if you use ctrl+\ you get a bunch of goroutine stacktrace outputs, which is kinda not pretty, but 🤷 .