code-server heartbeat logic

[rohinwork]

Description

I am running code-server with multi-tenancy and would like to know when to kill the users containers after a period of inactivity. I am using the heartbeat file that code-server touch's every minute for this.

I would like to know on what basis does code-server decides to touch the heartbeat, i.e what are the conditions that code-server decide as activity and inactivity.

[sr229]

A little dig on #1115 will let you know how it works.

[rohinwork]

@sr229 I had a look at this. However I am not able to gather under what conditions is the heartbeat function called.
ex scenarious:

• no websocket activity
• code-server view not in focus (code-server tab in background_

[sr229]

We don't have the ability to send that serverside. Even then, @Microsoft is more than concerned for this rather than us.

[code-asher]

If there have been any HTTP requests in the past minute or if there are
any active web sockets then the user is considered active.

An active web socket is one that is connected even if there is no
activity on it. So this includes idle users that just have the tab open
(even if it's in the background).

If the user closes the tab or their network connection dies then the
heartbeat will stop until they connect again.

There's currently no way to detect if the user is idle. I was thinking
about capturing idle data on the client-side (probably a timer based on
mouse and keyboard activity) then sending that through the socket to the
server but it's not implemented yet. Maybe we could show an "are you
still there?" message as part of that.

[antofthy]

Form my experience, while the browser has codeserver window open and the application is running (some browsers will stop the application) then the heartbeat file will update.

In other words while the user has it open. We terminate the docker environment code-server is running in, when the user had not performed a control operation (we have such operations touch heart beat file to simply matters) , or heartbeat has not been updated in more than 2 hours.

[rohinwork]

@code-asher Awesome! Thank's for your response. I am happy to contribute a PR for if you could let me know where to get started from.

Thanks :)

[nhooyr]

We don't need to send anything to the server, just disconnect the WebSocket if the user has been idle for an excessive amount time. Opening a new issue.

[rohinrohin]

Hi @code-asher - are you still looking for a feature for the "are you still there message"? (since we use it today to clean up resources - pods in kubernetes) This would be really useful to us and if the community also wants it I would be happy to work on this.

[code-asher]

Yeah, I'd be open to merging a feature like that. I think we initially decided not to because users will usually disconnect naturally (close the tab, close the browser, computer goes to sleep, I think even in some cases if the browser tab isn't focused it'll close the websocket), but I'm not sure how reliable that all is so a dedicated feature might be helpful.

[antofthy]

On start up I usually just try a curl request, and see if I get a 500 or a login redirection, looping until I get a response before reporting to the user they can proceed.

[rohinrohin]

@code-asher any suggestions on approach. Here's what I am thinking:

1. If we already have a function that's triggered on some user activity in the IDE I can hook to that with a timeout of say 'x' minutes and raise a "reconnecting.." like popup ("Are you still there" - Yes/No). If "No"/ response timeout then possibly touch a file that indicates user doesn't seem to be active. The popup will still be active and the user can choose to click yes at any point in that case the file will be deleted.
2. If we do not have the above, then raise this popup every 'x' mins to the user for the same functionality as above.

Any other suggestions/approach that you can share?

[code-asher]

I don't think we have anything specifically for user activity so we'd need to add something. My basic idea is:

1. Hook up event handlers to the body, probably keydown, mousemove, mousedown, scroll, touchstart.
2. Whenever those events fire update the last active time.
3. Add an interval that shows the popup if the last active time is greater than x minutes.
4. If the user does not answer the popup within a set timeframe disable automatic reconnection and disconnect the web sockets.
5. If the user comes back and answers the popup reconnect the web sockets and re-enable automatic reconnection.

The first three steps can all be done in lib/vscode/src/vs/server/browser/client.ts. The last two will involve modifying the existing reconnection logic in VS Code since right now it just always automatically reconnects and we need to be able to toggle that on/off.