The desired behavior makes a lot more sense to me, too.

I agree with the desired behavior. Thinking of this, I wrote some (probably incorrect) pseudo-logic around it in the RFC, that you should only be able to extend your workspace deadline up to the next auto-on time, assuming that at the scheduled auto-on, your deadline would refresh.

I don’t know if this is overkill for the RFC Solution, but I was thinking that we could allow auto-off to be extended until it is ≥ than the auto-on time.

Example:

Grey: 9am → 9pm

If I extend by 12+ hours, the backend will just 201 my request to extend. When 9am hits the following day, my workspace will still be on so that auto-on will no-op.

Logic looks like this:

const startTime = “09:00 2022-03-04” // assume mod 24
const offTime = “21:00 2022-03-04” // assume mod 24

let scheduled = offTime

func extend () {
nextTime = scheduled + “90 minutes”

if nextTime ≥ startTime && nextTime < offTime {
scheduled = offTime + “24 hours” // “21:00 2022-03-05”
return 201
} else {
scheduled = nextTime
return 200
}
}

Revisiting that, I don't know if it's helpful or not (the 201 on further bumping deadline), but I think the desire for deadline to reset if you're still on by the next auto-start time seems like expected behavior, so we're on the right path!

Hmm why don't limit Auto-Off to start_time_interval - 1?

@johnstcn how complex is this to do? I don't have an idea of it, but if it's trivial it might be nice to add to the EE milestone.

@johnstcn how complex is this to do? I don't have an idea of it, but if it's trivial it might be nice to add to the EE milestone.

I would hesitate to call this "trivial", but I think enough people have found it annoying for me to try to get it in anyhow!

We haven't gotten suggestions for this, so I'm closing for now!

I'm in support of making this change. Sometimes I restart the workspace in the evening (say 8pm) and with a normal schedule of 9:30am + 14h, this would result in autostop happening at 10am, at which point the workspace will be stopped when I try to login in the morning.

@deansheather is working on changes related to our scheduling behavior to avoid this. Basically, workspaces will only stop during "quiet hours" to prevent workspaces from stopping at inconvenient times, such as right before an autostart. Going to close in favor of that

@bpmct can you link to more details on how "quiet hours" are defined?

Yep: #8117

Quiet hours does not interact with regular TTL (only the "restart requirement") so this needs to be reopened. I think we should just change the activity bumping code to be like:

newDeadline := time.Now().Add(ttl)
if newDeadline.After(nextAutoStartTime) {
  newDeadline = nextAutoStartTime.Add(ttl)
}

We also need to change the initial calculation for deadline to have this extra clause too, in autostop.CalculateAutostop()

@deansheather - is this still on your plate

I had a PR for this but it went stale due to the offsite and my vacation. I don't think it's super high priority though TBH

Bumping this and re-opened the PR. We should bring it into this sprint.

A couple of our folks have noticed this quirk as well. Not having this breaks the assumption that your workspace will be up from autostart time to autostart time + autostop duration when using an auto-start schedule.

@bpmct @sreya I think this is a must-do for the upcoming sprint. Several customers have been experiencing unexpected workspace shutoffs due to Autostop issues. Solving this would both improve user experience and expedite debugging of other scheduling issues.

Sounds good to me.

We fixed this a while back!
290180b