Description
Context
A challenge we have with workspace timeouts is often that users are using the workspace, but are: pre-occupied with some other work on their computer, or are performing some actions that aren't necessarily detected by the timeout logic, e.g. testing an application running on a port, or using some client connected via SSH.
Whilst we continue to improve the workspace timeout logic, implementing a manual prompt which gives a user a chance to intercept a workspace shutdown could mitigate some of the user experience challenges surrounding workspace timeouts.
e.g. the Netflix "are you still watching" prompt.
Relates to:
- Ensure VS Code Desktop can reconnect to workspace after timeout #10288
- Epic: Restart workspaces directly from VS Code Desktop #9221
- Improve Gitpod timeouts for multiple clients (revise the 5 minute editor connection timeout) #10373
FAQs
If workspace is going to timeout, in most cases, it means user is not in front of their computer
We can validate this by looking at analytics for how quickly users restart stopped workspaces. Some scenarios where a user might be at their computer, but where our current heart beat implementation might not work (need to test):
- User runs an app + tests the app directly, and is not using the Gitpod workspace, but the app hosted in it
- User is connecting to the workspace from some other service, e.g postman to test out APIs developed in the workspace
- User is running some long running process, tests, analysis, web scraping, and is leveraging multi-track workspaces.
Can we quantify somehow what we are trying to improve with these actions, and when we should stop? i.e. some alert for premature or missing timeout?
- Would be useful