Shared workspace times out if workspace creator is idle but other collaborators are not

[Mob-Programming-Meetup-Austria]

Bug description

We run a frequent Mob-programming meetup, where gitpod serves us very well for collaboration with low setup overhead for our participants.

It looks like the session times out if the workspace owner is idle for some time, even if the collaborators are actively using it.

In our sessions, sometimes the main collaborators are different users than the owner of the workspace (and the repo). It would be nice if also the activity of other users would be checked.

Steps to reproduce

1. Start a workspace
2. Share the workspace with somebody else
3. Only interact with the workspace from the other user
4. Session will time out after a while

Workspace affected

bronze-iguana-w9e78jfb

Expected behavior

It would be nice if the workspace owner doesn't have to restart the workspace.

Example repository

No response

Anything else?

No response

Front conversations

[gtsiolis]

Thanks for bringing this up, @Mob-Programming-Meetup-Austria! 🍊

issue: This seems to conflict with the notion of ephemeral dev environments[1] and surface a way to exploit the platform as this could easily break user control[2].

thought: However and more importantly, I think the use case you are describing fits better when collaborating asynchronously and here Snapshots[3] could probably be a better way to share the workspace in the first place and allow collaborators to work on their own and possibly share a new workspace for the outcome. Also, in case this could help, there's also a feature to extend workspace timeout[4] for 180 minutes which is currently available in the Unleased Plan. 💭

Adding here the feature: collaboration label. 🏷️

Looping in @jldec for input.

[Mob-Programming-Meetup-Austria]

Thanks for the timly response and great suggestions @gtsiolis

Unfortunately our events are live and synchronous collaboration sessions. We rotate the "Driver" role every 3-5 minutes while we do mob-programming. Usually we set the rotation time so that the first driver is back at the "keyboard" after 20-30 minutes at least in the ideal case. Often while practicing it takes longer to do a full round within a group. This means we hit the default timeout quite regularly.

Thought: Would a notification (5-10 min before timeout is reached) be a potential mitigation of these conflicting "requirements"?

Thanks, Harald Reingruber

P.S. Here is a link to our meetup group, just in case you are curious: https://www.meetup.com/Mob-Programming-on-Open-Source-Software/

[gtsiolis]

@Mob-Programming-Meetup-Austria I think once we add better and more granular sharing (https://github.com/gitpod-io/gitpod/issues/4841) and introduce the new teams pricing (https://github.com/gitpod-io/roadmap/issues/17), it would be it easier to effectively tackle this use case. Cc @jldec @svenefftinge

For example, :a: using a team[1] for this meet up group and :b: sharing a workspace to all team members could make it easier to allow collaborators to continue working on a workspace without timing out while using team credits / billing / usage quota.

A notification before the timeout could easily go unnoticed and continue blocking users as the workspace owner could be unavailable. 💭

[dpolivaev]

I am also a member of the @Mob-Programming-Meetup-Austria group. I would like to clarify one point in our use case. Actually, the workspace owner is always present in the session. They are just not typing until becoming a driver again, but the connection with their browser is never lost. Therefore everything happening in the session is always observed by the workspace owner. If the timeout would not occur just because the owner is not typing while observing the running session it would be very helpful.

[stale[bot]]

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.

[stale[bot]]

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.

[PatelN123]

Commenting here to upvote this.

[Adamtaranto]

I want to upvote this too.

Issue: We have a shared workspace where we are working on edits that write to a local database within the workspace. Users are using this workspace asynchronously. If the workspace has timed out the workspace creator has to restart it, this is hugely impractical.

A bad but workable solution: I am upgrading to a paid account anyway which will allow me increase the timeout period. This is a waste of Gitpod's resources as the instance would essentially be always running in case a user wants to access the workspace. It would also waste credits on my account.

A better solution: Allow non-creator users of a workspace to restart the workspace using the share link OR have a shared workspace appear in another user's "gitpod.io/workspaces" list.
Currently users get this error when trying to access an idle workspace "missing create permission on workspaceInstance". If I could assign additional owners to a workspace I have created that would also solve the problem.

Not a solution: Snapshots are not a solution. As we are concurrently making edits to a db inside the workspace we must be using the same instance. Git cannot sync database edits. We also cannot currently modify the project to use a cloud db service.