When reviewing a PR in a container then the GHPR extension is not activated and requires a reload

[egamma]

Edit: Added steps to Repro

• Add following setting "extensions.webWorker": true to user settings file
• Have GHPR extension installed locally
• Clone the repository https://github.com/egamma/vscode-remote-try-node.git into a container volume
  🐛 GHPR extension is enabled locally (web worker)

When a PR is opened in a container the extension install the GHPR extension automatically, when it isn't already installed. The extension is installed in the same way as the other extensions defined in the devcontainer.json.

To reproduce, open a PR in a container, e.g., https://github.com/egamma/hello-extension2/pull/2.

Open the extensions viewlet, notice that the extension is installed but now requires a reload to be activated.
Also notice that when in the 'requires reload state' the activity bar shows the GHPR view container contribution (cached?). You can select the contribution and the view container opens but in some undefined state (see the 2nd screenshot below).

[egamma]

@sandy081 the GHPR extension behaves differently with regard to 'reload required':

• Installing the GHPR extension on the desktop doesn't require a reload
• Installing the GHPR extension in a container always requires a reload (when the GHPR extension is installed locally)

I'm pretty sure that this is a regression and that the GHPR extension could be installed into a container without reload.

The eslint extension doesn't have this issue and doesn't require a reload

To reproduce clone the repository https://github.com/egamma/vscode-remote-try-node.git into a container volume. This dev container installed both the eslint and the GHPR extension.

[sandy081]

I tried to repro and I see that dev-container extensions are installed and enabled properly.

Can you please check if extension is running or not using the command Developer: Show Running Extensions. It is strange that GHPR activity bar icon is shown but extension is not running. Since we disable activity bar icon caching in remote window, I think this icon is coming from extension but extension is not running on the remote.

Can you also please check if the extension is installed locally and if this got enabled?

[egamma]

It is as you expected the GHPR extension is running locally. For me it repros all the time.

What puzzles me is that once a do a reload from the extensions viewlet, then the GHPR extension is running remotely.

@sandy081 do you have the GHPR extension installed locally? When I uninstall the GHPR extension locally then the GHPR extension is properly activated and running remotely.

[sandy081]

Thanks @egamma for the info and it can be reproduced with following steps:

• Add following setting "extensions.webWorker": true to user settings file
• Have GHPR extension installed locally
• Clone the repository https://github.com/egamma/vscode-remote-try-node.git into a container volume
  🐛 GHPR extension is enabled locally (web worker)

Local GHPR extension is enabled on web worker because it can run on web worker (its extension kind is ['workspace', 'web'])and server does not include GHPR extension when the client (VS Code) asked for the installed extensions and here is the reason why this is happening:

Extensions from devContainer.json are installed while the server is being started and by the time client (VS Code) asks for the installed extensions, all extensions from devContainer.json are not included as they are still getting installed. These extensions are send to the client after they are installed and it is already too late as the client picked the locally installed extension that can run locally (web or ui) as a second preference.

@alexdima How about client wait to load only those extensions (can run locally as second preference) until server is ready (until all extensions are installed on server)?

There is also another option - when client asks server for the installed extensions, then make server to wait until all extensions are installed. But I am not sure if the installation takes more time and the client times out if the extension host is not started by then.

[alexdima]

@sandy081 I believe the initial issue with the GHPR extension no longer reproduces due to how we have phased out extensionKind: "web". But the general case you mentioned probably remains. i.e.:

How about client wait to load only those extensions (can run locally as second preference) until server is ready (until all extensions are installed on server)?

@sandy081 I think you have implemented this functionality in the meantime and maybe the only task left here is to make sure we use the correct arguments when launching the server in dev containers?

[sandy081]

Dev containers previously was installing the extensions first and starting the server after. With my changes (to improve perf), it is starting the server and installing the extensions in parallel. This triggered this issue as the client starts loading extensions before all extensions are installed on the server. I think asking Dev containers to go back to first approach is not a good idea because it blocks starting the server until extensions are installed. So, I think this has to be fixed on client side while reading and loading extensions.

Since we disallow extensions to include web extension kind and we do not add web extension kind automatically in desktop, I think we can close this as we might not encounter this scenario in desktop.