Workaround: stop it by clicking "Stop." I think being able to shorten is good, but given that you can click "Stop" I'm not too stressed about it.

This isn't a bug; it's a missing function.

Counterpoint: If you no longer need the workspace, it's the same amount of effort to just stop it as it is to run, say, coder unbump my-workspace.

"unbump?"

What about coder expire, and you can pass arguments like +30m or -2h?

My honest interpretation is that @ammario is imagining some kind of date in the UI as being editable in any direction, within constraints.

The data layer uses a TTL, but I think we can abstract that data concern from the interface representation.

Can you confirm @ammario ? I don't want to put words in your mouth, just what I'm sensing.

Workaround: stop it by clicking "Stop." I think being able to shorten is good, but given that you can click "Stop" I'm not too stressed about it.

This isn't a bug; it's a missing function.

Here's my user experience with the current behavior:

• It's noon, I realize it's probably going to be a late night, so I bump to midnight
• It's 4pm, I realize I'm actually going to get off at 10pm, max... Here I have a fork in the road.
• I can either shorten the auto-off schedule, then restart my workspace (which can takes minutes)
  • This could even fail if the TTL constraint is too high
• Or I can remember to turn it off manually at the end of my session
• As a user, I want to rely on one method of turning off my workspace, not multiple depending on my ability to calculate the ideal bump.
• The result is I'm afraid of bumping. I spend an extra 20 seconds thinking about the ideal bump. I think this is an unintended negative surprise. We don't expect users to spend 20 seconds thinking about the ideal bump. This is why I marked as "bug".

My honest interpretation is that @ammario is imagining some kind of date in the UI as being editable in any direction, within constraints.

Yes, I do think this is the ideal experience. It can work with TTL constraints by preventing you from putting it more than X hours in the future from now. When using an incremental bump value, it's unclear to the user whether it's applied to the current time or the existing deadline. Editing the time is far clearer.

I would suggest mapping the data layer to timestamp instead of TTL as well for these reasons:

• The API becomes idempotent, and thus retriable and more reliable.
  • User intent is not lost due to long processing delays. For example, if it takes a minute for the request to process, the resulting stop time is the same.
• We're using a PUT, which by REST standards should be idempotent (this is a minor one though).
• Again, the delta-based bump makes it unclear whether the API is adding the TTL to the current timestamp or the last deadline, introducing bug risk. I struggled with this personally as I went through the code last night.

Overall: I'm looking forward to our conversation this morning 😁

I'm not dismissing this as the experience we want. I just don't think it's important enough for this level of elaboration right now. I suggest putting up -30m and -2h buttons. Those are inverse replicas of the +30m and +2h buttons we have elsewhere, so they should be trivial to implement. Then we avoid API changes and adding new forms etc. to the UI beyond what is already in flight. In a couple of months we can come back to this.

@ketang

I think we may be misaligned on the LoE of tidying up this flow. If we go down a time-based approach, I wouldn't think that's more than 1 engineering day to solve.

From discussion:

• No API changes required as setting a workspace deadline is already time-based.
• Allowing negative changes to workspaces is possible by removing the code that says no.
• CLI: allow either a duration (+/-) or "kitchen time" for editing the deadline of an active workspace build.
  • Meaured from NOW for idempotency
• UI: [-] and [+] buttons to add or remove 1 hour from the time (?)
  • NOT IDEMPOTENT; adds or subtracts from existing deadline

I think we may be misaligned on the LoE of tidying up this flow. If we go down a time-based approach, I wouldn't think that's more than 1 engineering day to solve.

I don't think we're that misaligned. I don't want to spend a day on it. This is not critical for the next few weeks. It's an edge case of an edge case.

I think we may be misaligned on the LoE of tidying up this flow. If we go down a time-based approach, I wouldn't think that's more than 1 engineering day to solve.

I don't think we're that misaligned. I don't want to spend a day on it. This is not critical for the next few weeks. It's an edge case of an edge case.

This is not an edge case of an edge case. I wasn't doing anything weird last night and the exact situation that was outlined affected and severely annoyed me. Have you experienced this directly?

Edge case of an edge case and then some... for this to be a problem:

• You have to have a schedule
• You have to extend the expiration time as defined by that schedule for a the current workspace incarnation
• You have to decide that your expiration extension was too much
• You have to decide manually hitting stop when you're done is somehow not a viable option
• You have to think it was enough too much to bother you. In practice, nobody's going to care if one time their workspace stops 30 minutes later than ideal.

It annoyed you. Okay. I think your perspective is not necessarily the same as our typical customer.

Well anywhos, Cian and Grey believe this to be very simple to implement, and we're refactoring other aspects so it can be batched nicely. We agreed in a call this morning to implement already.

Closed via #2721