Store state on remote instead of browser

[abhay-ranawat]

Edit by @code-asher: Storing the state in the browser has (at least) the two following problems:

1. If you switch to another browser you have to open and configure everything all over again (what this issue was originally about).
2. It is impossible to seed the initial state like you could in native VS Code by writing to the JSON state file.

Original issue content follows.

OS/Web Information

• Web Browser: Chrome v91
• Local OS: Windows 10
• Remote OS: Ubuntu 20.04
• Remote Architecture: Debian
• code-server --version: 3.12.0

Steps to Reproduce

1. Open a new code server instance in browser and make some changes (eg : hide remote host).
2. Open the same instance in incognito tab.
3. The changed made above will not be reflected, and you have to make those changes again.

Expected

Till v3.11 the state of code-server was maintained across browsers.

Actual

The state is saved local storage instead of server and hence the changes does not reflect on browser changes.

Notes

scope === StorageScope.GLOBAL ? 'global' : this.payload.id; it is in workbench.web.api.js.map
Perhaps it's related to where the state is saved?
From discussion : #4185

[jsjoeio]

Thanks for opening this up @abhay-ranawat! We'll have to investigate

[benz0li]

I have the same issue.

It would be great to have this resolved with v3.12.1.

[jsjoeio]

It would be great to have this resolved with v3.12.1.

That's unlikely to happen given our bandwidth (just setting expectations) but at least we know multiple folks are experiencing this issue.

[abhay-ranawat]

It would be great to have this resolved with v3.12.1.

That's unlikely to happen given our bandwidth (just setting expectations) but at least we know multiple folks are experiencing this issue.

Given the changes made in code, everyone should face it (AFAIK) only few might be noticing it.

[benz0li]

Agreed. I noticed it because I regularly delete all cookies and site data that the browser stores. I don't mind setting an exception for the domains on which code-server is deployed, though.

It doesn't matter whether the state is stored in ~/.local/share/code-server/User/state or the browser 's site data - but it should be documented, which is the case.
👉 In order to reset the state, one has to either delete ~/.local/share/code-server/User/state or clear the browser's site data.

ℹ️ I had to delete folder ~/.local/share/code-server/User/state after I moved from debian:buster to debian:bullseye, because e.g. the new Python version was not displayed correctly in v3.10.2.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no activity occurs in the next 5 days.

[benz0li]

As for stale bot see https://drewdevault.com/2021/10/26/stalebot.html: This is a terrible, horrible, no good, very bad idea.

[code-asher]

https://drewdevault.com/2021/10/26/stalebot.html

That was a great read. In the past we would periodically run through old issues and close out ones that no longer were applicable (this is because things can change a lot when we update Code versions) and the stale bot moves that burden off us to those who opened the issue. We could just leave them alone but we felt like keeping issues up to date was part of good repository maintenance. Maybe there is a better solution, like labeling issues that are on the Code side with something like upstream and then adding stale or revalidate or something to those when we update Code?

For the browser state I did look into moving it back to the remote file system but it looked non-trivial so I abandoned that effort since we generally try to avoid patches that deviate too aggressively from mainline.

There might be a clean way to do it with a bit more investigation though or maybe upstream would be receptive of a change to make this behavior configurable.

[code-asher]

For now i believe we are going to leave this as-is. If someone wants to dive in and figure out how to move the state to the remote like we do with settings, a PR would be much welcome.

[KaKi87]

There might be a clean way to do it

How about a plugin ?

[code-asher]

How about a plugin?

Maybe! Something similar to settings sync, where it syncs the state to and from the disk maybe?

[KaKi87]

Yeah. Maybe more code-server features could be implemented as plugins and preinstalled for easy activation.

[code-asher]

I like that idea.

[code-asher]

Went ahead and re-opened, still no plans but I do think it would be nice especially since native settings sync does not work with code-server.

[fulllagado1]

What is being willed is to visual code work as Jupyter Lab does with workspaces, totally portable. In Jupyter Lab, if I run a python file at home computer and open Jupyter interface on work computer, I get the same screen. If I do in code server, I get a new screen and if I need to rerun the python file (mainly if it is a server app), I need to open a new terminal (original one became a ghost, vanished) find its pid, kill it and run again. If I open a next server, it even vanishes from forwarded ports panel, inducing to open a new terminal, start next server again, with a new port (the previous one is used, by a ghost process). Jupyter Lab guys figured out those problems in the beginning of Jupyter notebook classic as reporting already running terminals and made somehow web development easier done in multiple machines than visual code server.

[benz0li]

@fulllagado1 For your use case, use a terminal multiplexer such as screen or tmux.

[code-asher]

Seems the upstream issue for this was closed right away but maybe with enough upvotes we can get it changed without having to patch it here: microsoft/vscode#210775

[KaKi87]

maybe with enough upvotes we can get it changed without having to patch it here

In a century, maybe.

[mgerasimchuk]

Faced the same needs, and spent 2 days trying to find settings / "hack" the global state / load profiles during the first run and through the URL

It would be really great to have this possibility for store state on the server side.