Errors when multiple workspaces simultaneously try to install a new Python Language Server version

Updated description

If there is a new Python Language Server version available and multiple Python workspaces are restored when Visual Studio Code is opened (i.e. if “window.restoreWindows” is set to “all”), then all of the workspaces will try to install the new version simultaneously. All but one of the workspace will fail and display

We encountered an issue extracting the Language Server.  Reverting to the alternate, Jedi.  Check the Python output panel for details.

Source: Python (Extension)               Show output

in a popup, with something similar to

Downloading https://pvsc.azureedge.net/python-language-server-stable/Python-Language-Server-win-x64.0.4.24.nupkg...
Language server dowload complete
Unpacking archive... Language server extraction failed
Error: UNKNOWN: unknown error, open 'c:\Users\keating\.vscode\extensions\ms-python.python-2019.9.34911\languageServer.0.4.24\System.ComponentModel.Annotations.dll'

appearing in the Python Language Server log. It is then necessary to restart Visual Studio Code in order to use the Python Language Server instead of Jedi. As @karrtikr noted, It’s possible to continue using the Python Language Server on all workspaces even without restarting Visual Studio Code.

Original description:

Occasionally (maybe 10% of the time?), when I open Visual Studio Code I get the following error popping up in the lower-right corner:

We encountered an issue extracting the Language Server.  Reverting to the alternate, Jedi.  Check the Python output panel for details.

Source: Python (Extension)               Show output

If I click on the “Show output” button, then the output panel is opened with the following:

Downloading https://pvsc.azureedge.net/python-language-server-stable/Python-Language-Server-win-x64.0.4.24.nupkg...
Language server dowload complete
Unpacking archive... Language server extraction failed
Error: UNKNOWN: unknown error, open 'c:\Users\keating\.vscode\extensions\ms-python.python-2019.9.34911\languageServer.0.4.24\System.ComponentModel.Annotations.dll'

If I close Visual Studio Code and reopen it, then the error doesn’t happen again and I can use the language server. The file that’s mentioned in the error message (System.ComponentModel.Annotations.dll) exists on my hard drive and I can open it in Notepad++ with no problems (although it just displays a bunch of gibberish since it’s a binary file). Windows reports the file size as 162,384 bytes.

In case it’s relevant, I have multiple Visual Studio Code windows that I created using “Duplicate Workspace in New Window” and “window.restoreWindows” is set to “all”, so all workspaces open at the same time when I start Visual Studio Code.

Environment data

• VS Code version: 1.38.1
• Extension version (available under the Extensions sidebar): XXX
• OS and version: Windows 10, 1903
• Python version (& distribution if applicable, e.g. Anaconda): Python 3.6.2 64-bit
• Type of virtual environment used (N/A | venv | virtualenv | conda | …): virtualenv
• Relevant/affected Python packages and their versions: XXX
• Jedi or Language Server? (i.e. what is "python.jediEnabled" set to; more info #3977): Language Server

[KevKeating]

One thing to note here is that regardless of the errors, I was still able to use LS for all workspaces in the current session itself, no need to reload. So you can probably just ignore the errors.

Interesting! I admit that I never actually checked whether those workspaces had switched back to Jedi or not; I just assumed the error message was accurate and restarted. Good to know. I’ll update my edit to the initial comment.

[KevKeating]

I just ran into this issue again when VSCode upgraded the Python Language Server from 0.4.24 to 0.4.38. I opened VSCode and four workspaces were restored, all with Python files. Three of the workspace gave me the “We encountered an issue extracting the Language Server” error, but one workspace succeeded in installing the new language server. When I restarted VSCode, all four workspaces successfully used language server version 0.4.38. I think it’s safe to assume that a race condition from multiple workspaces trying to install the same language server at once is the correct underlying issue here. I’ll update the issue title and add a note to the initial comment clarifying things.

Thanks for the help, @karrtikr!