One potential issue is that the cancel job could succeed and the start or stop job fail, so the canceled state may not be totally avoidable.

I'd call that a failed job, same as if there were no cancelled job.

A "delete" also involves a job. Is this still considered a build/action? Can we cancel it?

What are the exact decisions needed here? I'm happy to try and weigh in.

I would like to include when this decision should take effect. Is this something that we are trying to bring in for Community? If so, go ahead and label it for Community.

@misskniss this is not needed for Community. I just wanted to create a place for the discussion to live.

@spikecurtis @f0ssel sorry, I stopped a little short because I realized this isn't a priority just yet.

Yes, delete has to be considered as well because it can also be canceled.

Spike, it sounds like you might be proposing a change to the API rather than just the frontend, where it sends back a failed job status if a double job (cancel then something) partially fails. That dovetails with Garrett's push to have the frontend do less derivation.

As long as we have cancellation functionality with a name that users can understand, we can take as long as we want. I think cancellation is necessary for Community, but perfectly-named cancellation is not.

Leaving this as is for Community. We can come back to it.

I just wanted to drop a gif of the resulting UI here (I think this is the right ticket) because I encountered this again today and thought the indeterminate state was a little confusing - you can see the user is presented with both start and stop options:

Regardless of how we choose to handle this on the BE, it would be nice to lend a little more clarity to the FE, maybe by hiding some buttons or something.

Oh yikes, having both start and stop is not good not at all.

Oh yikes, having both start and stop is not good not at all.

Wait, why? If I cancel a Start, why is it wrong to Start again? Why is it wrong to Stop?

If your workspace incarnation i is currently stopping, I think you shouldn't be able to hit the stop button again. It won't do anything. The presence of the active stop button implies that previous attempts to stop didn't take. I also think (for now) you shouldn't be able to spin up incarnation i+1 because we haven't validated the need nor designed a UI that can unconfusingly represent that.

Start / Stop / Delete are being shown after the Action is cancelled, not while the workspace is stopping.

I agree that if the Stop build action is currently pending/executing (both I believe are interpreted as Stopping in the UI), you can't Stop again. But if you Cancel the Stop, then you should be able to run a new Action with any transition.

In that situation you shouldn't be able to run Start, so it avoids the problem of having Start and Stop buttons simultaneously.

This issue is becoming stale. In order to keep the tracker readable and actionable, I'm going close to this issue in 7 days if there isn't more activity.