Improve Gitpod timeouts for multiple clients (revise the 5 minute editor connection timeout)

[loujaybee]

Currently, a workspace will initiate a 5 minute timer from close of any active editor. This current behaviour assumes too much that the user is operating a single client connection. Gitpod should be smart enough to recognise when a user is making multiple connections and not time out when a user swaps between SSH, VS Code or JetBrains with a workspace.

However, in scenarios where there are two editors open, this timeout should not be triggered. Ideally, we initiate the timer from the last active editor, to prevent breaking workflows where two editors are used. We should also check: https://github.com/gitpod-io/website/issues/2144 - to ensure the timeout logic is fully documented.

See internal link [1]

[jeanp413]

I didn't know about the 2 minutes timeout and I've hit this multiple times lately while testing the SSH stuff in gitpod-desktop extension, and it was really annoying 😄

[loujaybee]

Associated with: https://github.com/gitpod-io/customers/issues/57

[loujaybee]

If this is purely a cost-saving mechanism, we could look to modify the behavior only for certain cohorts

e.g. customers on X plans, etc?

[akosyakov]

First timeout is 3 min, not 2. Second i think 3 mins to switch between editors should be more than enough, if a user does not do for 3 mins i would say we should stop. I think we should improve communication about timeouts somehow.

But maybe it is just a bug in hertbeating? What was the reason for the issue?

[iQQBot]

it's 2min, configmap from prod.

The problem is that we set the close flag on all client exits, including SSH, which means that if you accidentally disconnect from SSH, i.e. network issue, close your laptop lid, you need to reconnect within two minutes or the workspace will time out

This behavior is actually not reciprocal, in vscode browser, the close flag is only set if you explicitly close the tab, but disconnecting, or closing the laptop lid will not cause workspace to close prematurely, but this happens with SSH connection, if your network is unstable for more than 2 minutes, workspace will close, which is not friendly

[akosyakov]

The problem is that we set the close flag on all client exits, including SSH, which means that if you accidentally disconnect from SSH, i.e. network issue, close your laptop lid, you need to reconnect within two minutes or the workspace will time out

Can we distinguish graceful closing of a connection? We should not timeout on network issues and so on.

[iQQBot]

Can we distinguish graceful closing of a connection? We should not timeout on network issues and so on.

researching

[iQQBot]

https://gitpod.slack.com/archives/C01KPEPNBD0/p1654682744017129?thread_ts=1654676308.765119&cid=C01KPEPNBD0

[jeanp413]

I think API heartbeat should have priority over ssh heartbeat, example:

• User has vscode web or vscode desktop connection to a workspace and external ssh connection from terminal
  • If external ssh connection closes, use last api heartbeat logic i.e. 30 min timeout if vscode web or vscode desktop connection still open otherwise set timeout to 2 min
• If there's only external ssh connection, set timeout to 2 min

[akosyakov]

We discussed to add more logs/analytics to learn about timeouts and SSH closing conditions.

[jkaye2012]

Just want to note that this has been impacting our team as well - developers are confused as to why workspaces are closing well before the 30 minute timeout and this seems to be the likely culprit

[akosyakov]

We agreed to extend the close timeout to 5mins for now: https://github.com/gitpod-io/ops/pull/2967

[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.