Workspace "about to" timeout prompt

[loujaybee]

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):

1. User runs an app + tests the app directly, and is not using the Gitpod workspace, but the app hosted in it
2. User is connecting to the workspace from some other service, e.g postman to test out APIs developed in the workspace
3. 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

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[filiptronicek]

From a quick discussion with @akosyakov:
This will be fairly easy to do if we always had only one window -> we could do most of this on the client-side, but when you introduce multiple windows (even with features like workspace sharing), it would need a lot of restructuring of our heartbeat code (i.e. move heartbeating to supervisor).

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.