Workspace idling in VS Code should not happen if a background process is running

[l0rd]

Is your enhancement related to a problem? Please describe

When a user is not interacting with VS Code for more than a given amount of time (specified in checluster devEnvironments.secondsOfInactivityBeforeIdling), the workspace get stopped automatically. This can be frustrating as long running task started in the cloud dev environment (i.e. a build or ML task) will be aborted if the user doesn't interact with IDE.

Describe the solution you'd like

There can be a few options: 1) Configure the VS Code extension che-activity-tracker to track also events like onDidChangeActiveTerminal or onDidChangeTerminalState 2) Introduce a new Devfile attribute to allow disabling workspace idling 3) Introduce a new Devfile attribute to allow avoiding idling if specific processes are running

Option 1) looks the simplest although if the long running process doesn't produce an output the workspace will get idled anyway.

Option 2) disable idling completely for the workspace using the devfile but that may be overkill (we still when the long running task have completed and the user is not active).

Option 3) would be the more effective but require more in intrusive changes (machine-exec and devworkspace-operator) and still require.

Describe alternatives you've considered

There are a few workarounds to disable idling for a single workspace today:

• Manually disable che-activity-tracker after starting a workspace
• Add the env variable SECONDS_OF_DW_INACTIVITY_BEFORE_IDLING="-1" in the devfile

[l0rd]

Downstream issue

[amisevsk]

One concern with implementing this is that it might be hard to distinguish between e.g. a long-running task with a purpose (an ML workload, etc.) and a long-running task that is just a non-terminating task (e.g. starting the program for debugging).

I wonder if it might be possible to add functionality so that commands can enable/disable idling automatically -- for example, you could set a specific command to disable idling until it completes while letting idling occur naturally for other non-terminating commands. This could work similar to finalizers on k8s resources, where if there are any finalizers left, idling does not stop the workspace despite having timed out normally.

[l0rd]

I wonder if it might be possible to add functionality so that commands can enable/disable idling automatically -- for example, you could set a specific command to disable idling until it completes while letting idling occur naturally for other non-terminating commands. This could work similar to finalizers on k8s resources, where if there are any finalizers left, idling does not stop the workspace despite having timed out normally.

Yes that's a good idea too. But if the developer has a the terminal open and a command running in it, we should not idle the workspace. No matter if the command doesn't explicitly disable idling. If that's easy to implement (option n.1) then we should go with it.

[RomanNikitenko]

@l0rd about option 1

Configure the VS Code extension che-activity-tracker to track also events like onDidChangeActiveTerminal or onDidChangeTerminalState

I quickly reviewed the extension and it looks like the extension already tracks both events (onDidChangeActiveTerminal and onDidChangeTerminalState)

[l0rd]

@RomanNikitenko you are right. Any idea on event triggered when some output is shown in the terminal window?

[RomanNikitenko]

Any idea on event triggered when some output is shown in the terminal window?

I think you ask about this event.

I checked that the event is fired for both:

• a terminal
• a task

when data is written to a terminal.

Potentially, this event can be used as a quick solution for the current issue. But this event doesn't fix the problem for the use cases when a process is running & there is no output (like, output was first few seconds => then there is no output during hours). Also, please pay attention, that the event was added as a proposed API due to problems around performance (see https://github.com/microsoft/vscode/issues/78502#issuecomment-518548517).

So, ideally, we should track running processes, like: a user runs a task => idling should not happen while the corresponding process is running.

[vitaliy-guliy]

Could it be implemented on the backend? I just think what if I launch a long-live task and closed my laptop. When I will open it in few hours I expect that my task and the workspace are alive.

[che-bot]

Issues go stale after 180 days of inactivity. lifecycle/stale issues rot after an additional 7 days of inactivity and eventually close.

Mark the issue as fresh with /remove-lifecycle stale in a new comment.

If this issue is safe to close now please do so.

Moderators: Add lifecycle/frozen label to avoid stale mode.

[RomanNikitenko]

/remove-lifecycle stale