Can't open vscode offline in WSL when there is update

[hamza512b]

• VSCode Version: 1.49.3
• OS Version: wsl

Steps to Reproduce:

1. Make sure you are offline and don't have the lastest version of vscode
2. Open WSL (Windows Subsystem for linux)
3. run "code " to open vscode
4. Vsode will delete and try to update even if you are offline.

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

[hamza512b]

I been frustrated by this, because I don't have access to internet all the time. I end up using another editer.

[hamza512b]

This is what I am taking about:

❯ code .
Updating VS Code Server to version d2e414d9e4239a252d1ab117bd7067f125afd80a
Removing previous installation...
Installing VS Code Server for x64 (d2e414d9e4239a252d1ab117bd7067f125afd80a)
Downloading: 100%
Failed
Will not apply HSTS. The HSTS database must be a regular and non-world-writable file.
ERROR: could not open HSTS store at '/home/hamza/.wget-hsts'. HSTS will be disabled.
--2020-10-12 18:31:20--  https://update.code.visualstudio.com/commit:d2e414d9e4239a252d1ab117bd7067f125afd80a/server-linux-x64/stable
Resolving update.code.visualstudio.com (update.code.visualstudio.com)... failed: Temporary failure in name resolution.
wget: unable to resolve host address ‘update.code.visualstudio.com’
ERROR: Failed to download https://update.code.visualstudio.com/commit:d2e414d9e4239a252d1ab117bd7067f125afd80a/server-linux-x64/stable to /home/hamza/.vscode-server/bin/d2e414d9e4239a252d1ab117bd7067f125afd80a-1602520270.tar.gz

But sometimes it is different error too. Because sometimes it doesn't fully xdownload.

[gabrieledcjr]

any updates on this issue?

[pluma]

This makes VSCode unusable on spotty WiFi or if you have to restart VSCode for any reason after losing connection for an extended period of time (flight, outage, whatever). At this point I'm now considering leaving VSCode Remote for VSCode running in WSL itself just to avoid this problem.

I don't understand why it's not possible to have the old server continue to work with the new client for non-breaking releases. This seems like a design oversight given that client-server architectures normally don't use all-or-nothing versioning.

[Kif11]

tl:dr It seams like on what @aeschli mentioned at #5104 an update get triggered if vscode mismatch vscode server. Base on that fact a workaround could be disabling Auto Update in VSCode settings.

I definitely agree with @pluma and the fact that every new version is not compatible with previous version of WSL server make very little sense.

This quite unreasonable and painful behavior. To add a bit more details to this issue the problem is coming from bootstrap script wslDownload.sh

Here is the piece of code that remove the previous version.

	# This version does not exist
	if [ -d "$VSCODE_REMOTE_BIN" ]; then
		echo "Updating VS Code Server to version $COMMIT"

		# Remove the previous installations
		echo "Removing previous installation...";
		rm -rf "$VSCODE_REMOTE_BIN"/????????????????????????????????????????
		rm -rf "$VSCODE_REMOTE_BIN"/????????????????????????????????????????-??????????
		rm -rf "$VSCODE_REMOTE_BIN"/????????????????????????????????????????-??????????.tar.gz
	fi

I guess one solution could be is to check for internet connection before removing. However it seam unsound to do it in this download script. I'm trying to understand what trigger VSCode to update in the first place in case user is offline. I think, it would make most sense to do offline check before triggering the update procedure and just fall back to the installed version of VSCode server.

[pluma]

Would it be possible to prevent VSCode from auto-updating when exited while offline, if the remote extension is installed?

[pluma]

I could also imagine VSCode's auto-update having a notification like "A new version of VSCode has been downloaded in the background. VSCode will be updated the next time you exit the application" with a button for preventing that. Or at least a flag to prevent the auto-update while offline.

[buddudevelopers]

sible to have the old server continue to work with the new client for non-breaking releases. This seems like a design oversight given that client-server architectures normally don't use all-or-nothing versioning

I use wsl with visual studio it still does the very same thing

[devqueue]

same issue. Has this been resolved?

[dneise]

just ran into this issue on the train.

Windows seemed almost workable when using WSL ...

[hamza512b]

@dneise Eaxtly. Although strange that someone listened.

[hamza512b]

Maybe @Kif11 knows how to fix the problem.

[firxworx]

+1 I hit this on a flight this month thanks monthly update cycle. Even more discouraging was learning that there is seemingly no straightforward way to disable this behaviour, e.g. no quick flag to start it up anyway.

I think the following sequence is shortsighted where the previous installation is deleted first, and then fetching the new version is attempted:

$ code .

Updating VS Code Server to version 8dfae7a5cd50421d10cd99cb873990460525a898
Removing previous installation...
Installing VS Code Server for x64 (8dfae7a5cd50421d10cd99cb873990460525a898)
...

Seemingly another manifestation of MSFT-branded product overlooking real-world on-the-road use-cases re the lack of thoughtful/elegant handling :-P. No doubt y'all work hard, please take a real vacation one day and venture off the grid for a bit to experience this first hand!

In case it is not clear, the desired behaviour is:

• Developers should not be blocked from using VSCode in cases where an Internet connection is unavailable or intermittent (important: including any extensions that they may depend on).
• VSCode provides developers an elegant path to start-up in a scenario where docs/web/etc. are assumed to be inaccessible (i.e. no assumptions that the dev is in a position to look anything up / no data can be fetched; for example, if a seamless startup can't/won't be implemented, the command output to code in WSL2 on failure should suggest flag/alternate command to unblock the developer and get them coding).

A not-great quick workaround to suggest for now is if you plan on coding while on the go is to start VSCode before you embark and leave it open...

However beware there are still cases where VSCode can still get a bit hairy and require a full re-start -- e.g. a case would be if some extension updates were installed automatically in the background while a connection was still available.

[hamza512b]

Maybe you are talking gold, but maybe also you should not be using WSL, in flight?

No offense intended

[aeschli]

Unfortunately, our implementation mandates that the client and the server version match. A client cannot work with a server that has a different version. Keeping the old server doesn't help, we simply can't use the old server anymore, unless you revert the version of the client.

But yes, I understand that this is a real issue. Ideally the VS Code installer we could bundle the client and server download.

[hamza512b]

There is a reason why we all use Vscode. It is not perfect, but good enough.

I want for Vscode to be fixed, and maybe "a client and server download" is the way to go. Otherwise, there are may be other solution, such as delete the broken code from now.

[firxworx]

@hamza512b why close the issue?... at this time there is no resolution?

[hamza512b]

@hamza512b why close the issue?... at this time there is no resolution?

Just, open new issue.
Thank you

[aeschli]

I reopen the issue, I hope we sometimes find time to look at it.

[CharlieDerby]

I am also experiencing this issue. I just tried to open VS Code in WSL on a train and couldn't get any work done because I couldn't download the new version.

It feels ridiculous that the way VS Code is designed prevents me from performing entirely local tasks when offline.

[bhaskoro-muthohar]

I have this kind of issue. Is there any workaround?

[mzinsmeister]

In my opinion a good solution would be giving the user a checkbox in settings to check that says "force download of new remote server on WSL (or "the following wsl distributions") with VSCode update" or sth. like that. I would find that beneficial anyway since it would possibly also reduce the time i wait for VSCode on WSL to start when i actually need it.

[ScriptPup]

+1 on this issue. My WSL is isolated from the rest of our network by IT policy so I simply cannot use VSCode in WSL because of this :(

[danilojr-delacruz]

I'm not sure if this is a fix, but this stackexchange post which set update.mode to none makes you skip the update when you run code.

[iolpltuisciaoln]

And so, vscode obviously falls into disrepair if the Internet is missing somewhere, great!

[ThobiasAggerholm]

+1 on this issue.

[themegabyte]

okay so this was frustrating, my 4G was not fast enough and I had to just abandon coding altogether, sigh, I have currently disabled auto update so both versions don't update at all.

[amirjj]

for those from Iran who encountered this issue and are not on a flight or a train, don't be confused that's because our fucking government has filtered VSCode URLs for some ridiculous reason (I don't know may be there is no reason and Mullahs are just retarded). just used a VPN to other countries or other editors.

[pluma]

@amirjj I think that may actually be GitHub/Microsoft trying to comply with export regulations.

[r-rumenov-ag]

I'm not sure if this is a fix, but this stackexchange post which set update.mode to none makes you skip the update when you run code.

This is gold! I disabled updates on the client, manually installed vscode-server inside wsl and disabled its updates too.

I don't know how insane you must be to assume a developer will always have internet when working. Clearly, the "vscode client doesn't match server" explanation is an cheap cop-out, since you can always check whether they match first, not just delete the server and reinstall it...

[iolpltuisciaoln]

If the editor versions are different, why not simply upload the one that is currently running.

[Bibelo]

I'm not sure if this is a fix, but this stackexchange post which set update.mode to none makes you skip the update when you run code.

so you basically have to start VScode to disable a setting to be able to start it

[nbstrong]

I'm not sure if this is a fix, but this stackexchange post which set update.mode to none makes you skip the update when you run code.

so you basically have to start VScode to disable a setting to be able to start it

You should be able to edit the settings.json file without opening VS Code.

[meidix]

@amirjj I think that may actually be GitHub/Microsoft trying to comply with export regulations.

Nope. That has nothing to do with Microsoft or GitHub fortunately. It's all about the decision that these illiterate people governing my country make DAILY:))))
If there is any workaround to this problem, it would be much appreciated

[dpypin]

I'm also affected by this issue. In my case I have internet, but HTTP endpoint from which update is downloaded is not available:

[2023-02-09 01:12:32.380] Downloading server on client side to C:\Users\username\AppData\Local\Temp\vscode-remote-wsl\e2816fe719a4026ffa1ee0189dc89bdfdbafb164\vscode-server-stable-linux-x64.tar.gz.
[2023-02-09 01:12:32.380] https://update.code.visualstudio.com/commit:e2816fe719a4026ffa1ee0189dc89bdfdbafb164/server-linux-x64/stable
[2023-02-09 01:12:53.453] Unable to download server on client side: Error: Request downloadRequest failed with message: connect ETIMEDOUT 40.64.128.224:443. Will try to download on WSL side.

[aeschli]

Fixed in WSL extension 0.76.0 (for the upcoming VS Code release 1.76)