BUG: Plugin store not updating in a timely manner when a new plugin ver released

[deefrawley]

Checks

• I have checked that this issue has not already been reported.

• I am using the latest version of Flow Launcher.

Problem Description

I updated General Converter to v2.0 over 12 hours ago. Plugin manifest picked up the changes shortrly after, but Flow Plugin Store hasn't updated and shows version 1.4 still

Using pm install installs v1.4

Tried reinstalling Flow, and hitting Refresh in the Plugin Store but no update.

This must update eventually otherwise there would be no plugin updates since the last change, but it should be much quicker than this.

To Reproduce

No response

Screenshots

No response

Flow Launcher Version

1.14.0

Windows Build Number

Microsoft Windows [Version 10.0.19045.2846]

Error Log

Log shows that a manifest update occurred:

09:56:51.9743+10:00 - INFO - PluginsManifest.UpdateManifestAsync - Fetched plugins from manifest repo

[github-actions]

This issue is stale because it has been open 45 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[JohnTheGr8]

I also noticed this today and had a look... it's caused by the CDN we use in PluginsManifest.cs#L15. jsDelivr caches for 12 hours.

We can switch back to a direct Github link, but Chinese users will have issues 🤷‍♂️

[jjw24]

Good pick up @JohnTheGr8. I don't suppose there is any settings with the CDN we can tweak to reduce the cache time?

[JohnTheGr8]

they offer a limited-access API for purging cache that we could use from the CI script... but it shouldn't be worth the trouble.

Maybe we should use a Github link by default and either:

• fall back to jsdelivr if the github link fails
• make the manifest URL configurable from settings
• or both of the above

[jjw24]

they offer a limited-access API for purging cache that we could use from the CI script... but it shouldn't be worth the trouble.

Maybe we should use a Github link by default and either:

• fall back to jsdelivr if the github link fails
• make the manifest URL configurable from settings
• or both of the above

This might be our last resort.

If It's a simple API call to purge, we can do that after the manifest is updated.

@taooceros do you know any other viable CDN options?

[JohnTheGr8]

This might be our last resort.

keep in mind that their docs state:

To avoid abuse, access to purge is given after an email request (for now - dak@prospectone.io).

@taooceros do you know any other viable CDN options?

Other CDNs will also cache for a few hours ;)

[JohnTheGr8]

btw I tried their online purge tool the other day and, while it said it succeeded, the purge didn't propagate correctly for me (they use a combination of cloudflare, fastly and gcore for CDN).

Testing through a server in another country I got an up-to-date response, but from my location I was getting outdated content for a few more hours... 😢

[jjw24]

OK, so the purge tool doesn't sound reliable enough.

Other CDNs will also cache for a few hours ;)

I haven't played much with CDNs in general, anyone else have any input? @Flow-Launcher/team

[JohnTheGr8]

To elaborate a bit further, a user-configurable manifest URL (like an option between github, jsdelivr or user-defined) would also have the following additional benefits:

1. it will be possible to have "unofficial" plugin communities, which means the whole ecosystem is a bit more open
2. it will make it possible to do full integration testing of plugins: for example, before opening a PR to the manifest repository to add a new plugin, I can point my flow-launcher to my fork repository and test that a complete install/update/etc works as expected...

I understand this is not necessary at this point, we can leave that for later... ;)

[jjw24]

I have been wanting to enable this since day 1 👍 will create an issue. #2178