Vscode: When relaunching for 1.43.0 update, vscode tries to open ~80 old workspaces

[thomcc]

Issue Type: Bug

After updating to 1.43.0, when VSCode relaunched, it brought up around 80 editor windows from old projects I hadn't opened in quite some time. (spooky workspace necromancy)

Perhaps obviously this made my computer behave quite poorly. I tried adding "window.restoreWindows": "none" to my <config>/User/settings.json with another text editor, but it didn't seem to be respected (might be my fault somehow). Note that it had been on "folders" previously, in case that helps.

I also tried to muck about with <config>/storage.json file. VSCode seemed to ignore my changes to it (probably not a bug -- I was desparate and dunno how this file works), but I do have a backup of a storage.json from right after this happened. It shows all the windows it will try to open when launching, and maybe other stuff. If there's no PII concern beyond the file paths I can upload it. I guess the system info probably has more PII anyway. I dunno how much this helps but: https://gist.github.com/thomcc/c4f9a745d940d8e0bfd5d28946c73bdc

I think the main common feature of the workspaces it resurrected seemed to be that they had open files with unsaved changes -- but these are also the ones which can't be closed without additional UI confirmation, and I did try a couple things to close all windows in bulk (none seemed to work, but maybe I just didn't notice?)

Relaunching without extensions also didn't help, but that doesn't mean this wasn't caused by an extension in the first place or somethign. I have more than is probably reasonable installed. That said, it happening immediately after updating to 1.43.0 makes me think it's vscode and not an extension.

Anyway, ultimately I just bit the bullet and closed them manually -- VSCode would be usable for about 20 seconds after starting, during which time I could close a few before too many were restored and everything got too slow. So i just did this, quit, and repeated many times until there were no more left (this actually took a couple goes -- even when I'd get down to none left, save, and reopen, it would find some new ones to bring back... Guessing these just didn't make the cut for being restored the previous time, or something)

P.S. it would be nice if there were a command line argument to launch without reopening anything.

P.P.S. In case it isn't clear: I've been using editor, workspace, and window somewhat interchangably here, just so you don't think I'm being precise about which I use when.

VS Code version: Code 1.43.0 (78a4c91400152c0f27ba4d363eb56d2835f9903a, 2020-03-09T19:34:44.548Z)
OS version: Darwin x64 18.7.0

System Info

|Item|Value|
|---|---|
|CPUs|Intel(R) Core(TM) i9-8950HK CPU @ 2.90GHz (12 x 2900)|
|GPU Status|2d_canvas: enabled
flash_3d: enabled
flash_stage3d: enabled
flash_stage3d_baseline: enabled
gpu_compositing: enabled
metal: disabled_off
multiple_raster_threads: enabled_on
oop_rasterization: disabled_off
protected_video_decode: unavailable_off
rasterization: enabled
skia_renderer: disabled_off_ok
video_decode: enabled
viz_display_compositor: enabled_on
viz_hit_test_surface_layer: disabled_off_ok
webgl: enabled
webgl2: enabled|
|Load (avg)|3, 21, 51|
|Memory (System)|32.00GB (2.52GB free)|
|Process Argv||
|Screen Reader|no|
|VM|0%|

Extensions (55)

Extension|Author (truncated)|Version
---|---|---
code-gnu-global|aus|0.2.2
better-toml|bun|0.3.2
glsl-canvas|cir|0.2.8
bracket-pair-colorizer-2|Coe|0.0.29
dart-code|Dar|3.8.1
xml|Dot|2.5.0
scopes|dua|0.45.0
gitlens|eam|10.2.1
vscode-html-css|ecm|0.2.3
tslint|eg2|1.0.44
vsc-material-theme|Equ|32.5.0
vsc-material-theme-icons|equ|1.1.4
prettier-vscode|esb|3.20.0
vscode-test-explorer|hbe|2.17.0
vscode-peacock|joh|3.6.0
language-haskell|jus|2.7.0
center-editor-window|kai|2.3.0
chat|kar|0.31.0
restructuredtext|lex|120.0.0
fish-ide|lun|0.4.0
regionfolder|map|1.0.8
Kotlin|mat|1.7.1
rust-analyzer|mat|0.1.20200309
Lisp|mat|0.1.10
ninja-syntax|mel|1.0.0
prettify-json|moh|0.0.3
vscode-json5|mrm|1.0.0
vscode-docker|ms-|1.0.0
csharp|ms-|1.21.13
sublime-keybindings|ms-|4.0.6
vscode-typescript-tslint-plugin|ms-|1.2.3
vsliveshare|ms-|1.0.1711
vsliveshare-audio|ms-|0.1.80
vsliveshare-pack|ms-|0.3.4
debugger-for-chrome|msj|4.12.6
idl|myt|0.3.1
autotrim|Nat|1.0.6
proto|pet|0.0.2
material-icon-theme|PKi|4.0.1
polacode|pnp|0.3.4
tcl|ras|0.1.0
crates|ser|0.4.7
trailing-spaces|sha|0.3.1
vscode-scheme|sjh|0.4.0
fish-vscode|sky|0.2.1
shader|sle|1.1.4
rewrap|stk|1.9.1
shellcheck|tim|0.9.0
org-mode|too|0.5.0
cmake|twx|0.0.17
vscode-lldb|vad|1.5.0
vscode-icons|vsc|10.0.0
material-theme|zhu|3.2.3
vscode-open-in-github|ziy|1.3.6
tslint-snippets|zuo|1.1.0

(11 theme extensions excluded)

[thomcc]

I tried adding "window.restoreWindows": "none" to my /User/settings.json with another text editor, but it didn't seem to be respected (might be my fault somehow).

FWIW this does seem to be respected now and I haven't changed anything, maybe indicating that it was being ignored for some reason during all this? Not sure if this is important, but worth noting I guess.

[dijitali]

Hit the same issue here, VSCode opened up a few hundred projects after upgrading and my mac nearly fell over:

Version: 1.43.0
Commit: 78a4c91400152c0f27ba4d363eb56d2835f9903a
Date: 2020-03-09T19:34:44.548Z
Electron: 7.1.11
Chrome: 78.0.3904.130
Node.js: 12.8.1
V8: 7.8.279.23-electron.0
OS: Darwin x64 19.3.0

[bpasero]

Yeah, I expected this to happen. Works now "correctly" after @aeschli pushed https://github.com/microsoft/vscode/commit/55307ef33097a619bac96f94cd6c8f4a3f1cc60d

This is expected hot exit behaviour to restore workspaces that have backed up files.

[DanielRosenwasser]

Hit this last night as well and it completely froze my machine up for minutes opening at least 40 windows. I get why this is an expected fix for a bug, but I it made my computer totally unresponsive and probably could have used a more progressive one-time rollout.

[Tyriar]

So it looks like this was a regression in 1.42 (https://github.com/microsoft/vscode/issues/90949) and it's now fixed as it's designed. It's designed this way so that by default, backups don't go "missing" by accidentally closing window(s) and forgetting which one had your notes in it.

I can attest to the fact that it's awful when many windows unexpectedly restore as it happened to me when testing settings sync. I'm not sure what the right recovery fix is but you can workaround this in the meantime by setting "files.hotExit": "onExitAndWindowClose" in your settings.json file manually. To go back you would need to either delete the backup files manually (../Backups/ from the setting.json's folder) or open the workspaces and close unsaved files.

[DanielRosenwasser]

Just to clarify, for anyone coming to this thread who's hosed with 40+ windows, it sounds like what you're saying is the workaround is

• set files.hotExit to onExitAndWindowClose so that we don't have to go through a ton of different "do you want to save this?" prompts when we try to close every window.
• set window.restoreWindows to none (or another reasonable setting) so that VS Code doesn't try to open a ton of windows for every workspace with unsaved files.
• delete the unsaved buffers manually until things are bearable again.

Is that the recommendation?

[phiat]

@DanielRosenwasser

• set files.hotExit to onExitAndWindowClose

Is all I needed to stop the window tsunami.

[Tyriar]

@DanielRosenwasser if you just set "files.hotExit": "onExitAndWindowClose" you should be fine if you then open a new folder (code somedir) and then close the window. This is actually how I've always used hot exit and recommend it if you haven't tried, it takes the rails off and was meant so that you can close windows arbitrarily even on macOS as well as not restoring all windows with backups whenever VS Code gets launched.

If you want to go back to "onExit", deleting the buffers manually after reviewing is probably the best way to go.

[Tyriar]

I'm struggling to find a way to properly fix this for users without just changing the behavior something since this change in behavior looks to have been in since 1.32. Maybe some restriction on the maximum number of windows that can be opened at once, with a dialog if it's over 5 or something?

@bpasero do you know what the behavior was before? foldersToAdd seems to add folders to a the active workspace, does this mean all workspaces with folders were getting restored into a single window, or did they get dropped somehow?

[bpasero]

@Tyriar I am quite sure we opened 1 window per backup directory with backups. So ended up always restoring every window that has backups. We decided with this approach to ensure we always bring back dirty files into their windows independent from any setting (other than the hot exit one at least).

Btw untitled workspaces behave exactly the same for the same reasons because they may contain setting changes that are unsaved.

[Tyriar]

@bpasero I think you're describing the designed behavior, I mean to ask about the behavior from 1.32 to 1.43 so that it's clear how having foldersToAdd caused the backups to behave and why backups stacked up not getting restored (was this because they weren't being saved to workspaces.json anymore?).

[bpasero]

I think @aeschli can comment if there was some intention behind the change or just an oversight.

To be clear: I would never expect a folder with backups to be added to a workspace to turn it into a multi-root workspace.

[ryenus]

One thing might be considered, as discussed with @thomcc in Gitter, is to limit the number of windows/workspaces to be restored upon start, such as 10 at most, which might relieve this "correction".

[aeschli]

We decided to fix this by reverting the change and no longer restore the folders with unsaved content. That was the behavior from 1.32 to 1.42 and as we didn't get any complaints, this seems to be practical.
You can always open these folders from the recent menu, and unsaved content is restored.

I created #92467 as a followup issue for the next milestone. We plan to also no longer restore workspaces (except unsaved/untitled workspaces) and we will add more information to the recent menu to show which folders/workspaces have unsaved content.

[aeschli]

To verify:

• set "files.hotExit": "onExitAndWindowClose"
• open 2 windows, each opened on a folder. Make a unsaved change or add a untitled file with content
• close both windows. There should be no questions asked, exit VSCode
• open VSCode on an other folder (code ~/foo). Only one window should appear