Fall back to downloading server from the remote VM when local download has failed

[mjwang455]

Type: Bug

My system (SAW) updated VS code from 1.82 to 1.85.1. The new version failed to connect to docker container on Azure VMs. And there is no option to roll back to 1.82. Here is the error message:

[11613 ms] Installing VS Code Server for commit 0ee08df0cf4527e40edc9aa28f4b5bd38bbff2b2
[11614 ms] Start: Downloading VS Code Server
[11614 ms] 0ee08df0cf4527e40edc9aa28f4b5bd38bbff2b2 linux-x64 stable
[12687 ms] Failed to download VS Code Server (https://update.code.visualstudio.com/commit:0ee08df0cf4527e40edc9aa28f4b5bd38bbff2b2/server-linux-x64/stable): HTTP 502 - Proxy Error Microsoft Forward Proxy denied the URL. Access is denied
[12687 ms] Retrying to download VS Code Server.
[13731 ms] Error: XHR failed
at k.onerror (vscode-file://vscode-app/c:/Program%20Files/Microsoft%20VS%20Code/resources/app/out/vs/workbench/workbench.desktop.main.js:95:2027)

Please help. Thanks.

[chrmarti]

The server for 1.85.1 needs to be downloaded, if the SAW's security policy doesn't allow this anymore (it appears to have worked with 1.82), there is not much we can do on the VS Code / Dev Containers side. Could you raise a ticket with the SAW support? Thanks.

[mjwang455]

Thanks, Chirstof.

[fei-xx]

The server for 1.85.1 needs to be downloaded, if the SAW's security policy doesn't allow this anymore (it appears to have worked with 1.82), there is not much we can do on the VS Code / Dev Containers side. Could you raise a ticket with the SAW support? Thanks.

@chrmarti Actually wget https://update.code.visualstudio.com/commit:0ee08df0cf4527e40edc9aa28f4b5bd38bbff2b2/server-linux-x64/stable inside the container could work. It seems the security policy did not block the link.

[chrmarti]

@fei-xx The extension downloads the server from the Windows side. It seems there the policy applies while it does not apply inside the container? Might this be a loophole that will be closed in the future? Might be best to discuss with the team managing the policy.

[fei-xx]

@chrmarti Thanks for the response. Here is more context about how we connect the container:

1. the remote-ssh extension and dev-container extensions are installed with the VS code on the SAW;
2. use remote-ssh extension to connect the Azure VM (succeeded, and I also saw the log shows the vscode server was downloaded or reused);
3. On remote-ssh window, we used dev-container extension to connect the docker container launched on the Azure VM, and then met the above issue that the vscode server could not download the vscode server. However, when I login to the container, wget VSCODE_SERVER_URL could run successfully.

In my understanding, the dev-container extension dowlnloads the server from the Azure VM side instead of the SAW windows side. Please correct me if I'm wrong. In addition, the traffic of docker container is transferred via the host Azure VM. Since remote-ssh worked well with the Azure VM, would dev-container be supposed to work as well?

BTW, is it possible to manually download the vscode server for the dev-container extension?

[chrmarti]

Makes sense, that's correct except the Dev Containers extension is downloading the server on the local machine, not the remote VM.

You could download and extract the server to the vscode Docker volume on the VM. You probably have the old server already there, see /vscode/vscode-server/bin and subfolders on the volume. Part of the server path is its commit id like in the download URL.

I will reopen this issue to track falling back to downloading from the VM when the local download has failed.

[fei-xx]

Makes sense, that's correct except the Dev Containers extension is downloading the server on the local machine, not the remote VM.

Got it. Thanks for the explaination.

You could download and extract the server to the vscode Docker volume on the VM. You probably have the old server already there, see /vscode/vscode-server/bin and subfolders on the volume. Part of the server path is its commit id like in the download URL.

Yeah, after manually downloading the server, the dev-container could work now.