Vscode hangs if an unbuilt local workspace extension is installed

[AndrewNolte]

Steps to reproduce:

1. Open vscode over ssh
2. Make a fresh clone of this repo (or git clean -fdx to remove the node_modules/ from the local workspace extension, and uninstall it if installed)
3. Install the vscode-selfhost-test-provider local workspace extension
4. Reload window, it should hang

When doing this locally, I get Cannot activate, becase ./out/extension.js not found. It's not clear from the docs that the extension needs to be built. However over ssh it gets vscode into a bad state.

Proposals:

• local workspace extensions should allow built vsix packages to be used instead, similar to how https://marketplace.visualstudio.com/items?itemName=garmin.private-extension-manager works
• Users should be able to be install them globally so they don't have to install the extension per worktree

[sandy081]

It is unclear and confusing to me what you are asking for. Summary and Description are not matching.
Summary says VS Code is unusable and I do not see anything related to that in the description.

[AndrewNolte]

Updated the issue! Sorry I was trying to be concise. After the reload is when it happens. And I did a bit more testing, this only happens over ssh. I was able to install a local extension over ssh when it was built though, so this only happens when it's not built

[pcasdf]

Updated the issue! Sorry I was trying to be concise. After the reload is when it happens. And I did a bit more testing, this only happens over ssh. I was able to install a local extension over ssh when it was built though, so this only happens when it's not built

Do you mean that if the extension's .vsix is in the extension dir, then the workspace will load?

A bunch of devs at my company ran into this too and our code-workspace got into a broken state. We have a few custom extensions in the .vscode/ directory at the root of our monorepo, and I moved them to .vscode/extensions, but it's just the source code and no .vsix. Although https://code.visualstudio.com/updates/v1_88#_local-workspace-extensions implies that this feature is opt-in, on Insiders only, with the extensions.experimental.supportWorkspaceExtensions config, none of which are true for us, we were still prompted to install workspace extensions. After doing so and reloading the extension host, the workspace never loads over SSH. Even after reverting the change and restoring the extensions back to their original location, e.g. .vscode/hello-world-extension, and removing the .vscode/extensions dir, the workspace still wouldn't load. I discovered that I had to rm -rf ~/Library/Application\ Support/Code/CachedConfigurations locally in order to be able to load the workspace again.

[AndrewNolte]

No I never made a vsix, just the compiled out/ dir needs to be there for local workspace extensions. It doesn't rely on a vsix at all, but I wish it had the option for it since not every repo has a node build system as part of its normal setup

[AndrewNolte]

Also @pcasdf, it's no longer insiders only https://code.visualstudio.com/updates/v1_89#_local-workspace-extensions

[pcasdf]

Also @pcasdf, it's no longer insiders only https://code.visualstudio.com/updates/v1_89#_local-workspace-extensions

Oops, I need to read the release notes more carefully 😇 well that's unfortunate since it doesn't seem ready to be on stable.

[sandy081]

Thanks for filing the issue and sharing your feedback. This is a bug in remote set up which I fixed it.

Thanks.

[NoReasonKen]

Is there a workaround to fix this issue by myself ? I cannot access server with remote-ssh now.

I deleted the .vscode/extensions folder under my workspace, yet the issue still remain.

I suppose there shall be a way to delete the installed workspace extensions by myself to prevent the issue hang remote server ?

[AndrewNolte]

Same, I tried running rm -rf ~/Library/Application\ Support/Code/CachedConfigurations locally like @pcasdf mentioned, but mine still hangs

[NoReasonKen]

I have fixed this.

1. Search the .vscdb file of the remote-ssh session in local.
   For example: I connect to remote from windows, and vscode store files under %appdata%\Code\User\workspaceStorage. There are many hashed name folder, you can connect remote-ssh session (of course, hanging) and close, then the most recent modified folder shall be the target. Remember check the workspace.json in the folder to ensure that.
2. Use any sqlitebrowser open the .vscdb file, and filter key with "workspaceExtension", there should a nearly matched record and it's value is those workspace extensions you installed.
   Sorry I have delete the record hence cannot remember the exact key name.
   Remember to close any vscode connection to the remote before opening the db file, vscode will cache one while connecting remote, so any modifications to db files is useless if any connection to the target remote exists.
3. Remove the record and commit your change to db file, re-connect to remote and it should no longer hang.

[AndrewNolte]

Thanks! It didn't seem like the storage was too important, it seemed to just record open files and UI data. So I just moved the folder on my remote and local to get a clean state. This seems like the wrong place to store workspace extension data. I really think the implementation of local workspace extensions needs to be better thought out if it can cause failures like this.

[vscodenpa]

This bug has been fixed in the latest release of VS Code Insiders!

@AndrewNolte, you can help us out by commenting /verified if things are now working as expected.

If things still don't seem right, please ensure you're on version 405ce83 of Insiders (today's or later - you can use Help: About in the command palette to check), and leave a comment letting us know what isn't working as expected.

Happy Coding!