Do not attempt to open a workspace/folder that no longer exists when reloading window

[alyssajotice]

• VSCode Version: 1.51.1
• OS Version: Win10

Steps to Reproduce:

1. Join Live Share Session
2. Close VS Code window
3. Wait up to 5 days
4. Open VS Code
5. VS Code tries to rejoin the Live Share session, causing an error message

Does this issue occur when all extensions are disabled?: Yes

I am on the Live Share team and we are working on fixing the above described issue. When we activate the Live Share function, we remove the current Live Share workspace from the VSCode list of 'recently opened' workspaces. To fix the bug, we propose that VSCode doesn't try to reload workspaces upon opening that are not in the 'recently opened' list.

[bpasero]

To fix the bug, we propose that VSCode doesn't try to reload workspaces upon opening that are not in the 'recently opened' list.

We cannot do that. A user might have many windows open and then clear the list of recently opened files before quitting. The next startup would not restore any of the windows. I do not think this is a good solution, hence closing.

Maybe the Liveshare extension could trigger the "Close Folder" command to bring the window back to the non-remote case?

[alyssajotice]

Hi @bpasero, I am reopening this issue. The Live Share team is still trying to come up with a solution to our reopening workspace issue described above. We have tried a few different approaches, but we need more information from the VS Code API to fix it properly.

Our ideal behavior is to always rejoin a session upon reload and always leave a session upon closing VS Code. We have some flexibility when it comes to reload behavior, but Live Share reloads in certain scenarios therefore we would also need the ability to reload and rejoin for those scenarios.

Based on your suggestion above, I tried closing the Live Share workspace during deactivation via:
await vscode.commands.executeCommand("workbench.action.closeFolder");
Adding this command to deactivate had no affect, appearing as though it does not have time to finish executing before VS Code performs the close or reload.

We also tried deleting the workspace file in deactivate, but it leaves VS Code in a bad state upon reload.

Another approach we tried was adding the deactivation timestamp to the global state and then trying to deduce whether VS Code performed a reload or reopen based on the time period in between Live Share's deactivation and activation. We aren't comfortable making this assumption so we would prefer a different approach.

We also opened #110034 about differentiating reload from reopen, which would give us the information necessary to solve the problem.

Based on this information, do you have any recommendations for how we should proceed?

cc @fubaduba @taiyosogawa

[bpasero]

We also tried deleting the workspace file in deactivate, but it leaves VS Code in a bad state upon reload.

Where is the file located on disk, do you create an actual workspace file to open or is it an "untitled" workspace?

I just conducted a local experiment and found the behaviour to be OK:

• create a local workspace file
• open it in VSCode
• close VSCode
• delete the workspace file
• open VSCode
• it opens an empty instance

I think this flow should work for you?

[alyssajotice]

We create an actual workspace in Temp. The "bad state" is upon the reload action, not close/open. Because we can't differentiate between reload and close/open, we must find a strategy that works for both actions.

If I delete the workspace in deactivate(), then reload, VS Code shows "Visual Studio Live Share (Workspace)" at the top and no Live Share extension button on the side, with no files open for coediting. To get back to the VS Code startup screen, you must do a File->Close Workspace.

The following gif shows what this end state looks like. I deleted the file manually in the gif but the same thing happens if it is deleted in deactivate.

[bpasero]

@alyssajotice yeah I see. arguably when a workspace file is deleted and you reload we should probably just open an empty window instead of pretending the workspace file exists. Would that help?

[alyssajotice]

Yes. Then we could have consistent behavior across reload and reopen - both leaving the session.

We do perform reloads as part of Live Share but we can handle that scenario with a flag to identify it as a LS triggered reload and not delete the workspace in deactivate for that situation.