Open SilentException opened 1 week ago
@SteamDeckHomebrew/decky-testers priority on testing this one out so it can be released as part of v3.0.1!
This fixes it by reading the plugin name from plugin.json file that is included in the ZIP.
https://github.com/SteamDeckHomebrew/decky-loader/pull/578#pullrequestreview-1842550498
https://github.com/SteamDeckHomebrew/decky-loader/pull/578#discussion_r1465647944
This fixes it by reading the plugin name from plugin.json file that is included in the ZIP.
Interesting, but it is not working as intended. The current code is deriving plugin name
from folder name in the ZIP and then searching for that same name
by traversing ~/homebrew/plugins
and looking into plugin.json
for the name.
Here are steps to reproduce and also test the fix.
You need GH actions run for new version of HLTB plugin: https://github.com/SteamDeckHomebrew/decky-plugin-database/actions/runs/10836675929 Not all plugins can trigger this bug (it depends on folder and plugin name).
It's a zip in a zip type scenario so unzip one layer first. Try to manually install the ZIP. The installation will hang - not hang the system but hang as not finish, indefinitely - you can still cancel it. Plugin files will be extracted but noting will happen after that. After cancelling, you will not see plugin in the plugin list either (without restart)
Remove the previously installed plugin (if you want a clean state) and install the PluginLoader from this PR. Do the same manual ZIP installation - everything will be fine this time. Plugin will be installed, progress bar will move forward and Decky will show the new plugin in the list.
Please tick as appropriate:
Description
This fixes issue: N/A
After debugging why plugin manual ZIP installations sometimes fail to finish and gets stuck I've noticed that plugin name is being extracted from folder name that is in the ZIP and not from the plugin.json file. This name is then used to search for plugin folder later on in the process (
plugin_folder = self.find_plugin_folder(name)
) and since the plugin folder name is pretty much guaranteed to be different than plugin name - assertion (assert plugin_folder is not None
) is triggered.This fixes it by reading the plugin name from plugin.json file that is included in the ZIP. It might also be a good idea to check why the installer gets stuck when the assertion error is triggered but it is out of scope for this PR.