Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

vsx-registry: Skip extension resolution if already installed #10624

Merged
merged 3 commits into from
Jan 21, 2022

Conversation

msujew
Copy link
Member

@msujew msujew commented Jan 12, 2022

What it does

Closes #10560 by comparing the versions of already installed extensions with the to-be-resolved extension version. When the extension already exists and its version is greater or equal to the one that should be installed, its download is skipped.

How to test

  1. Install the hbenl.test-adapter-converter and hbenl.vscode-test-explorer (in this exact order) extension from here. The hbenl.vscode-test-explorer version has been increased to 2.42.0 to recreate the original issue.
  2. Search for the "Mocha Test Explorer" (hbenl.vscode-mocha-test-adapter) and install it. It requires the hbenl.version-test-explorer as an extension dependency.
  3. In the console where Theia was started, the message [hbenl.vscode-test-explorer]: is already installed with the same or newer version '2.42.0' should appear.
  4. Confirm that no old version of the test adapter extension has been downloaded into your <user>/.theia directory.

  1. Repeat all of the above but instead of installing the extension from the .vsix file, unpack the extensions into your plugins folder. Additionally perform the test by adding the .vsix directly to the plugins folder without unpacking them.

  1. Restart the application and also confirm here that no downgrade is performed.

Review checklist

Reminder for reviewers

@msujew msujew added plug-in system issues related to the plug-in system vsx-registry Issues related to Open VSX Registry Integration labels Jan 12, 2022
@msujew
Copy link
Member Author

msujew commented Jan 12, 2022

cc @luettmaSICKAG this should fix the issue you were experiencing. Do you mind testing this PR to confirm that the resolution works as expected?

@luettmaSICKAG
Copy link

cc @luettmaSICKAG this should fix the issue you were experiencing. Do you mind testing this PR to confirm that the resolution works as expected?

Hmm sadly not completely. I couldn't test it with your plugins and the public OpenVSX marketplace due to our company proxy and no support in Theia yet.
I tested it with this branch and our private OpenVSX marketplace though.

The issue we have is a little bit different to the test you described in the PR.
Our problem is that the dependency is downgraded (in your example the hbenl.test-adapter-converter, not the hbenl.vscode-test-explorer).

When installing the plugins manually (from vsix) everything seems to work correctly (no downgrades).
When the dependencies are built-in they're resolved correctly during installation, but after a restart it just tries to download/update all plugins and seems to ignore the check.

Logs
I have renamed the plugins/files in the log entries, but haven't removed anything.
So this is what happens when I have a PLUGIN_WITH_DEPENDENCIES which depends on DEPENDENCY_A and DEPENDENCY_B.
DEPENDENCY_A and DEPENDENCY_B are provided built-in.
PLUGIN_WITH_DEPENDENCIES is installed manually ("Install from vsix"), but is also available in the Marketplace.

First start and installing the PLUGIN_WITH_DEPENDENCIES: 1_plugin-install-fresh-installation.log
Second start where the downgrade happens: 2_plugin-install-second-start.log

@msujew
Copy link
Member Author

msujew commented Jan 13, 2022

@luettmaSICKAG I was able to reproduce the dependency downgrade issue with the exact configuration that I use here as my testing steps on master.

Basically the extension dependency situation is as follows:

hbenl.vscode-mocha-test-adapter -> hbenl.vscode-test-explorer -> hbenl.test-adapter-converter

When installing my custom version 2.42.0 of hbenl.vscode-test-explorer through a vsix file, and afterwards downloading the hbenl.vscode-mocha-test-adapter extension using the vsx-registry UI, Theia automatically downloads the 2.20.3 version (a downgrade) of hbenl.vscode-test-explorer (which is an extension dependency of hbenl.vscode-mocha-test-adapter) and replaces the previously running version.

The hbenl.test-adapter-converter extension doesn't really have anything to do with it, it is just needed by the hbenl.vscode-test-explorer extension, but doesn't get automatically downloaded when installing the test explorer from the vsix file.

My PR fixes this exact behavior by identifying whether an extension dependency already exists in the list of deployed plugins and stops the extension resolution if the fetched version is not a version upgrade.

I hope that clears things up. Am I still wrong in the assumption that it mimics your setup?

@luettmaSICKAG
Copy link

Oh right sorry, I missed that. No the setup is correct.

Do you mind trying to test it with hbenl.test-adapter-converter and hbenl.vscode-test-explorer as built-in extension again and afterwards downloading the "Mocha Test Explorer"?
That'd be basically the same situation where I was still experiencing the issue.

@msujew
Copy link
Member Author

msujew commented Jan 13, 2022

@luettmaSICKAG No worries :)

I just retested the fix with unpacking the vsix files first and adding them to the list of built-in extensions. It still works correctly. I added the additional testing step to the original PR comment 👍

Copy link
Contributor

@colin-grant-work colin-grant-work left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have confirmed the bug on master and that this change addresses the issue. I have some misgivings about what happens in cases when this code does not apply and we do download a new version of the plugin, but this code reduces the frequency of that event, so it's at least a step in the right direction. 👍

@luettmaSICKAG
Copy link

I just tested it again on my private device, with your setup and the public OVSX registry.
I could still reproduce the problem with built-in plugins.

Not quite sure if the problem is on my side, so I just recorded it :s

What I did

  • I built Theia using yarn && yarn build
  • I added the two plugins from "How to test, step 1" to the /plugins directory of the repo (without extracting)
  • Cleared the directories %USERPROFILE%/.theia/extensions and %LOCALAPPDATA%/Temp/vscode-unpacked
  • Started Theia (electron) yarn electron start
  • Installed the "Mocha Test Explorer" ("How to test, step 2")
  • Restart Theia
  • Now hbenl.vscode-test-explorer is downgraded and installed to %USERPROFILE%/.theia/extensions

VSX_Builtin_Downgrade

@msujew
Copy link
Member Author

msujew commented Jan 20, 2022

@luettmaSICKAG Thanks for looking into this again. You're right, when restarting the app, the plugin resolving mechanism starts a second time, this time downloading the outdated version, since the plugins aren't deployed yet. I'll look into a solution for this 👍

@msujew
Copy link
Member Author

msujew commented Jan 20, 2022

@colin-grant-work Do you mind checking out step 6 of the testing steps? My newest changes fixes a restart-related downgrade issue. Previously, system and user extensions where resolved independently of each other when starting the plugin host, resulting in a downgrade of system extensions when a user extension depends on it. This only happens for packed extensions, since it is part of a racing condition.

this.logMeasurement('Deploy plugin entry', startDeployTime);
}

protected async deployMultipleEntries(pluginEntries: ReadonlyArray<string>, type: PluginType = PluginType.System): Promise<void> {
Copy link
Contributor

@colin-grant-work colin-grant-work Jan 21, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this (and resolvePlugins) the change that requires the introduction of the UnresolvedPluginEntry interface? It looks like previously we could only have a list of plugins with uniform plugin types, and now we want to have a list of plugin with mixed types. Otherwise, it looks like the same information was being passed around everywhere, just not necessarily in the same struct package?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Exactly, we need the mixed type since we need to resolve all user and builtin extensions in the first step. Though it's mostly resolvePlugins, since the main culprit of this issue is introduced here:

const [userPlugins, systemPlugins] = await Promise.all([
this.resolvePlugins(context.userEntries, PluginType.User),
this.resolvePlugins(context.systemEntries, PluginType.System)
]);

Copy link
Contributor

@colin-grant-work colin-grant-work left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I confirm that the new changes also prevent the inappropriate loading of dependencies during startup - the existing builtin plugins are used to satisfy the dependencies of user plugins.

@msujew msujew merged commit d6e4971 into master Jan 21, 2022
@msujew msujew deleted the msujew/vsx-check-version branch January 21, 2022 21:37
@github-actions github-actions bot added this to the 1.22.0 milestone Jan 21, 2022
federicobozzini pushed a commit to ARMmbed/theia that referenced this pull request Aug 24, 2022
…-theia#10624)

* Existing extensions are skipped on extension download
* All extensions are considered for dependencies during startup

Signed-off-by: Federico Bozzini <Federico.Bozzini@arm.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
plug-in system issues related to the plug-in system vsx-registry Issues related to Open VSX Registry Integration
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Installing a VSCode extension always reinstalls its dependencies
4 participants