In other words, you want to distinguish between extending this workspace incarnation's lifetime versus extending the lifetime for every future incarnation.

Thoughts:

Why would I expect it to change the lease at all?

The "change active lease" behaviour was added in #2165, the idea being that users would not necessarily differentiate between the workspace's "active lease" and the workspace's schedule.

I looked at the code a bit and have no idea what's causing this behavior.

What likely happened was that the active lease of the workspace had previously been extended, and updating the workspace TTL clobbered this previous lease. This is definitely not what a user would expect.

Possible solutions:

1. Make extending the workspace's "active lease" optional and opt-in (UI checkbox / CLI flag)
2. When updating workspace TTL, do not update the deadline of the active workspace build if it had previously been extended. This can be detected by comparing the time the provisioner job was completed plus the current workspace TTL to the deadline of the active workspace build. Alternatively, only update if the new deadline is after the current deadline, and not before.

We should definitely to 2) in any case; clobbering a previously extended workspace's deadline is not desirable behaviour.

@johnstcn I think we added #2165 because (at the time) there was no other way to extend the active lease. With the time-based approach, we can safely eliminate the coupling.

From discussion:

• When editing a workspace's scheduled shutdown time, the deadline of the active workspace build will no longer be updated.
• The time preview will be kept, but the CLI "are you sure?" nag is no longer neccessary. Ditto with the UI danger warning when the time goes down low enough.

My understanding (or how I think this should work) is that we only look at the schedule when we create a workspace. After that, we only look at that workspace's countdown. Is that right?

My understanding (or how I think this should work) is that we only look at the schedule when we create a workspace. After that, we only look at that workspace's countdown. Is that right?

Yes, correct. We used to do it that way but in #1783 we decided we should to tightly couple the scheduled shutdown time of a running workspace with the schedule of the workspace -- when the workspace schedule is updated, the actively running workspace's shutdown time also gets updated.

This is essentially reverting part of the work done in that ticket -- other work done in that ticket is still valuable (showing what the actual shutdown time would be based on changing the schedule).

This should be fixed by #2282. Please re-open if not.