Clicking the "update" button performs the following actions:

• Updates the template version referenced by the workspace to the latest version of the linked template
• Stops the workspace
• Starts the workspace

The underlying issue here appears to be the perception of "restart" being different than "stop" followed by "start", which is not the case.

@matifali can you clarify the impact of this issue? Is it just confusing, or is there a bigger knock-on effect that I'm missing here?

@johnstcn It is just different from the perceived expected behavior. A workspace should strictly follow the autostart autostop schedule, and a version update in the middle of the day should not push the auto-stop deadline further.

@matifali Should restarting the workspace in the middle of the day also not push the auto-stop deadline further? What about stopping the workspace, waiting 1 minute, and starting the workspace again?

My main question is:- should a start within the autostop window of a previous start honour the previous autostop window?

@matifali Should restarting the workspace in the middle of the day also not push the auto-stop deadline further? What about stopping the workspace, waiting 1 minute, and starting the workspace again?

Yes

My main question is:- should a start within the autostop window of a previous start honour the previous autostop window?

Yes

Also @bpmct can add further comments. Maybe I misunderstood the expected behavior. My understanding is that autostart/autostop are for cost control and should be followed strictly unless the workspace is active at autostop time.(In that case we automatically bump the shutdown time) See: #2995

@matifali OK, so just to make sure we're both on the same page:

Say a user starts a workspace at $T_{start}$, and stops it manually at $T_{stop}$, there would exist a window of time between $T_{stop}$ and $T_{autostop}$.

If a user then starts their workspace again at $U_{start}$ such that $T_{stop} < U_{start} < T_{autostop}$, then $U_{autostop}$ should equal $T_{autostop}$. Is that correct?

                         | <-- starts in this window should  --> |
                         |     re-use the old autostop time      |
   |=====================|................|......................|
   T_{start}             T_{stop}         U_{start}              T_{autostop}

@matifali OK, so just to make sure we're both on the same page:

Say a user starts a workspace at Tstart, and stops it manually at Tstop, there would exist a window of time between Tstop and Tautostop.

If a user then starts their workspace again at Ustart such that Tstop<Ustart<Tautostop, then Uautostop should equal Tautostop. Is that correct?

                         | <-- starts in this window should  --> |
                         |     re-use the old autostop time      |
   |=====================|................|......................|
   T_{start}             T_{stop}         U_{start}              T_{autostop}

@johnstcn Yes, exactly. This is my understanding of the expected behavior.

I gave it a 2nd thought and there can be 2 situations.

1. In an enterprise environment where the workday starts exactly at 8 AM and the developer isn't allowed to keep the workspace running for more than 12 hours. They can set an auto-start at 8 AM and then automatically auto-stop at 8 PM after 12 hours. It should ignore any updates and restarts during the workday.
2. In a remote working setup where developers follow a flexible schedule, they should just disable auto-start but can enable auto-stop to be 12 hours + the latest start/restart/update time. They can also totally turn off auto stop as developers can stop when they want to consider a flexible setup.

In short. For autostop, we can keep our current behavior when there is no auto-start set but should strictly follow autostart time when it is set.

1. sounds like a use-case for quotas (https://coder.com/docs/v2/latest/admin/quotas)

@johnstcn #8115 may be related or conflicting with what you are thinking to do here.

The autostop TTL is the amount of time of inactivity before the workspace is autostopped. It's not related to the autostart time at all.

#8115 reworks max_ttl on templates and doesn't impact the inactivity TTL.

@deansheather, I could not understand how this is going to be addressed.