code-oss stuck on "Opening Remote..." after update from 1.72 to 1.77

[inga-lovinde]

This is a great extension, and it worked flawlessly with my setup (Alpine x64 + code-oss on desktop, Alpine x64 + vscodium REH on server) for quite a while.

However, after I've upgraded code-oss from 1.72.2 to 1.77.3, it almost stopped working: when I open my remote project I've been working on for half a year without any problems, in the left bottom corner, "Opening Remote..." keeps spinning, and while file explorer and text editor work, nothing else seems to: search doesn't work, code highlight does not work (everything is the same color), autocomplete doesn't work, etc.

I've tried removing ~/.vscod* from the server; next time I tried to open my remote project, this extension installed vscodium 1.77.3 to the server successfully, but this didn't solve the problem.

There are several errors in "Developer Tools" console:

ERR Cannot read properties of undefined (reading 'c'): TypeError: Cannot read properties of undefined (reading 'c')
    at C.toKey (vscode-file://vscode-app/usr/lib/code-oss/resources/app/out/vs/workbench/workbench.desktop.main.js:647:42328)
    at w.set (vscode-file://vscode-app/usr/lib/code-oss/resources/app/out/vs/workbench/workbench.desktop.main.js:647:42787)
    at w.l (vscode-file://vscode-app/usr/lib/code-oss/resources/app/out/vs/workbench/workbench.desktop.main.js:2627:11827)
    at w.initializeRunningLocation (vscode-file://vscode-app/usr/lib/code-oss/resources/app/out/vs/workbench/workbench.desktop.main.js:2627:12341)
    at q.eb (vscode-file://vscode-app/usr/lib/code-oss/resources/app/out/vs/workbench/workbench.desktop.main.js:2627:19355)
    at q.db (vscode-file://vscode-app/usr/lib/code-oss/resources/app/out/vs/workbench/workbench.desktop.main.js:2627:18952)

This one is the same as mentioned in https://github.com/jeanp413/open-remote-ssh/issues/44#issuecomment-1372867020. According to code-oss sources, the undefined it tries to read c from is the key of extensionHostKinds returned by determineExtensionHostKinds from code-oss extensionHostKind.ts. Which in turn can be tracked down to:

• determineExtensionHostKinds calling toExtensionWithKind for _localExtensions and _remoteExtensions;
• toExtensionWithKind creating new ExtensionWithKind(desc, ...) for every desc in extensions, and using its .key as the map key;
• (new ExtensionWithKind(desc, ...)).key returning ExtensionIdentifier.toKey(desc.identifier);
• ExtensionIdentifier.toKey(desc.identifier) returning desc.identifier._lower for non-string values of desc.identifier... except that minified JS in my code-oss does static toKey(a) { return typeof a == "string" ? a.toLowerCase() : a.c } instead.

So maybe the reason is still that remote returns unmangled information on extensions with ._lower field while minified JS in code-oss accesses .c instead. Even though from #44 it seems that this was fixed upstream. Maybe the reason is something else.

Another error I sometimes get in Developer Tools console logs when opening this remote project is:

  ERR Cannot get default system shell when there is no backend for remote authority 'ssh-remote+MY-SERVER-NAME': CodeExpectedError: Cannot get default system shell when there is no backend for remote authority 'ssh-remote+MY-SERVER-NAME'
    at Object.getDefaultSystemShell (vscode-file://vscode-app/usr/lib/code-oss/resources/app/out/vs/workbench/workbench.desktop.main.js:1726:6416)
    at async g.v (vscode-file://vscode-app/usr/lib/code-oss/resources/app/out/vs/workbench/workbench.desktop.main.js:1719:18520)
    at async g.r (vscode-file://vscode-app/usr/lib/code-oss/resources/app/out/vs/workbench/workbench.desktop.main.js:1719:17783)
    at async g.getDefaultProfile (vscode-file://vscode-app/usr/lib/code-oss/resources/app/out/vs/workbench/workbench.desktop.main.js:1719:17114)
    at async g.o (vscode-file://vscode-app/usr/lib/code-oss/resources/app/out/vs/workbench/workbench.desktop.main.js:1719:15825)

After debugging things in developer tools for a while: it seems that:

• First, some local terminal backend (with remoteAuthority: undefined) is registered with registerTerminalBackend;
• Then, getDefaultProfile is called for 'ssh-remote+MY-SERVER-NAME', and since no terminals for this remote authority are registered with registerTerminalBackend, getDefaultSystemShell throws an error;
• And a couple of seconds later, registerTerminalBackend is called with remote backend with its remoteAuthority set to 'ssh-remote+MY-SERVER-NAME'.

I'm not sure if this is a bug or just a malignant race condition, and if actual issues I'm having (with search / syntax highlight / etc not working) are related to this in any way. The remote terminal itself seems to be working in code-oss.

And finally, I get two more error messages in developer tools console:

workbench.desktop.main.js:620   ERR Error received from starting extension host (kind: Remote)
workbench.desktop.main.js:620   ERR The remote extension host took longer than 60s to send its ready message.

which is maybe related to the previous errors?

[jeanp413]

Hi @inga-lovinde, just to be sure, you are using code-oss and not vscodium in you local machine right? If so, then I imagine you've done some hacks like updating commit in product.json right? because by default code-oss and vscodium are not compatible. If all above if true then that's the issue, related to the linked issue https://github.com/jeanp413/open-remote-ssh/issues/44, it is indeed fixed but in the end daiyam (vscodium mantainer) decided to disable the mangling and code-oss doesn't I guess so now more than before code-oss and vscodium are not compatible anymore.

You can try using openvscode-server instead, you can check https://github.com/jeanp413/open-remote-ssh/issues/83#issuecomment-1523413445

[inga-lovinde]

Yes, I indeed patched code-oss product.json to turn it into vscodium previously (vscodium itself is not packaged for alpine).

Switching to openvscode-server helped, I just had to restore the original code-oss product.json and:

• Change serverApplicationName in product.json to openvscode-server;
• Add commit to product.json with the value corresponding to the value of commit in product.json from the relevant openvscode-server release;
• Update "Server Download Url Template" in extension settings to https://github.com/gitpod-io/openvscode-server/releases/download/openvscode-server-v${version}/openvscode-server-v${version}-${os}-${arch}.tar.gz.

And everything seems to work now.

The problem indeed was caused not by this extension, but by growing incompatibility between code-oss and vscodium.