Skip to content

bug: "Stops at" UI element does not reflect the set auto-stop value #5080

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
ericpaulsen opened this issue Nov 15, 2022 · 4 comments · Fixed by #5391
Closed

bug: "Stops at" UI element does not reflect the set auto-stop value #5080

ericpaulsen opened this issue Nov 15, 2022 · 4 comments · Fixed by #5391
Assignees

Comments

@ericpaulsen
Copy link
Member

What happened?

I'm running on 0.12.7. after setting my workspace auto-stop to 5 hours, the STOPS AT value did not change and continued to show 1 hour from the current time.

Screen Shot 2022-11-14 at 9 49 50 PM

Screen Shot 2022-11-14 at 9 50 05 PM

What did you expect to happen?

I expected my workspace STOPS AT value to be 5 hours from the current time.

@presleyp
Copy link
Contributor

The behavior only takes effect after you start the workspace again - note that it says "Your workspace will shut down 5 hours after its next start." I agree that it's surprising behavior, but the problem is that you could edit your workspace more than 5 hours after it started, making the instruction technically impossible to follow (though it could shut down immediately, but I don't know if that's ideal either). @bpmct what do you think?

@bpmct
Copy link
Member

bpmct commented Nov 21, 2022

The behavior only takes effect after you start the workspace again

Could we change this behavior to be effective immediately?

the problem is that you could edit your workspace more than 5 hours after it started, making the instruction technically impossible to follow (though it could shut down immediately, but I don't know if that's ideal either).

When a workspace schedule is edited, perhaps we should bump the TTL by 1 hour (and notify the user) to avoid immediate shutdowns. Perhaps this only happens if the calculated shutdown time is less than 1 hour from now. When the user has "activity" on their workspace (VS Code, SSH, websocket on coder_app), we also bump the schedule by one hour so this seems appropriate.

@bpmct
Copy link
Member

bpmct commented Nov 21, 2022

Alternatively, we could change the shutdown to stop at n hours after the workspace is edited, instead of from when it is started.

@dcarrion87
Copy link
Contributor

dcarrion87 commented Nov 22, 2022

Potentially unrelated but the whole auto stop is not reflecting entirely for us in 0.12.6: #5146

Stopping and starting makes no difference. Users expect this to reflect on running workspaces if it can be edited on a running workspace anyway.

Really annoying bug.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants