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

User is able to export the plugin list when synchronization process is not finished #198

Open
jotacoro opened this issue Jun 11, 2023 · 2 comments
Labels

Comments

@jotacoro
Copy link

Description

If you use the export option to export a list of the plugins installed, you will have the results of the preview for a .csv file or a .json file:
image

But there's a chance to export the list while the synchronization process is still running. In this case, the results of the preview for the .csv will be the plugins located on that time:
image

I can't figure out a definitive, correct solution, but I suggest to maybe block the Export button until the syncrhonization process is finished. My understanding is that the Export function should only handle relevant information for the final user.


Steps to reproduce

Step No. Description Used Data Actual Result
1 Click on "Sync" button - A synchronization process starts.
2 While synchronizing, click on "Export" button - A list of plugins is generated. The list of plugins includes all the values achieved until that moment, since the start of the synchronization.

Where was reproduced

----------
Windows 10 Pro 21H2
OwlPlug 1.23.0
----------
@jotacoro jotacoro changed the title Plugin list export results are updated while synchronizing User is able to export the plugin list when synchronization process is not finished Jun 11, 2023
@DropSnorz
Copy link
Owner

Hi @jotacoro !

Thank you for pointing out that because it's not an intended behavior. 🙂

The Context

The current state of the plugins (the list of known plugins) is stored in the persistence engine after each Sync. In the first versions of OwlPlug, the plugin state is updated once ALL plugins are scanned. So plugin state displayed is always "complete".

When a plugin is synced using Native Discovery, OwlPlug loads the plugin like a DAW to extract metadata. During this operation, a crash in the plugin can lead to a crash of the host (which is the entire OwlPlug app)

So when the app crashes, it's hard to understand which plugin is involved in the crash. To overcome this, now when we run a Sync, the previous state is cleared and updated on the fly during the sync progress. This way, when we restart the app after a crash we can see exactly where the previous scan stops and identify the problematic plugin.

I've implemented a sandbox to scan plugins in a sub-process and avoid crashes (#27). I'm still gathering feedback to enable this feature by default (#138). By using sub-processing there are sometimes issues with antivirus and OS security options.

Fix options / Workaround

It's not a major issue, but i agree, it's a bit strange when it happens. Here some possible ways to handle the problem:

  • Create some sort of versioning in the persistence context, to always display "complete" version of the plugin state. Seems too complicated regarding the added value.
  • When we open the export window, we use the plugin state active at that time but we don't re-fetch anything from the persistence. We won't avoid "incomplete" data but at least, things will not change between the switch from JSON to CSV. I think it's the best option
  • Add a warning message when a scan run in the background
  • Do nothing

@jotacoro
Copy link
Author

Hi @DropSnorz , thanks for the detailed context here.

If I have an opinion here, I'll go with a mix between the second option and maybe block the UI journeys while synchronizing plugins. An example could be the exposed in the description of the issue, i.e. blocking the Sync and Export buttons while synchronizing.

I know that this could be seen as more "restrictive" but what do you think?

Regards,

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants