Drop-in VS Code extension does not show up as Installed.

[tsmaeder]

Bug Description:

When I install a particular VS Code extension it does not show up as installed (even though it is uncompressed to the "deployedPlugins"-folder.

Steps to Reproduce:

1. Have gitlens installed from open-vsix
2. Download the spring-boot extension and put it into ~/.theia/extensions
3. Start Theia Electron
4. Observe: the command line output shows that the extension is being decompressed into ~/theia/deployedPlugins
5. Observe: eventually, gitlens and other installed extensions show up in the "extensions" view in the "installed" section
6. Observe: the spring boot extension never shows up
7. Observe: there are no commands starting with "Spring" available from the command pallette
8. Restart Theia electron (not reload, restart the whole process).
9. Observe: the spring-boot extensions is available and shows up in the extensions view.

Additional Information

• Operating System: Windows
• Theia Version: 1.48 master

[tsmaeder]

Note that this is not happening in the browser application, only electron.

[tsmaeder]

I tried the same scenario with only the "github-authentication" plugin from microsoft, and that works. This might simply be a timing issue.

[tsmaeder]

Other difference: the spring-boot extension has redhat.java as a dependency.

[tsmaeder]

Installing via the extensions UI from open-vsx works fine. i.e. the extension shows up as "installed"

[tsmaeder]

Turns out in browser/hosted-plugin.ts#acceptPlugin(), sometimes returns false for a bunch of plugins.

[tsmaeder]

I finally got to the bottom of this: the problem came with the introduction of back-end plugins: there is a Deferred in hosted-plugin-deployer-handler.ts called backendPluginsMetadataDeferred. Since headless plugins are deployed using deployBackendPlugins(), the deferred gets resolved when deploying back and plugins. However, the deployment is done in parallel in plugin-deployer-impl.ts#deployPlugins(). Since there are no headless plugins, this "deployment" is very fast and the deferred gets resolved quite early. In the normal case, when no actualy unzipping of large plugins takes place, the list of plugins we get in the front end for loading contributions is complete. But when it takes longer, the list of plugins is incomplete: in fact, in my debug case it only includes about 1/3 of the actually installed plugins. The short term fix is to run the deployments in sequence and do the back end plugins first.

The long term fix for this would be twofold:

1. We need to start the front end in true parallel fashion: there is no need to wait for the initial "deyployment". We should just notify whenever we have "deployed" a new plugin an the front end should update itself in a sane fashion (i.e. batch updates, etc.)
2. We need to separate the headless plugins from the back end plugins: they are treated differently and we need to be able to distinguish between them.