[Bug] The latest version is not available as the old version is cached

[cyfung1031]

@JasonBarnabe The file cache issue is still here.

After the script is JUST updated via webhook.

• The script version is updated in Greasy Fork webpage
• The script version in the update.greasyfork.org is not yet updated. (no-cache is implemented)
• Both should align. If the script is not yet ready, the version in webpage shall not be the updated one.

This is verified by the fetch API, with option cache: 'reload'

In the DevTools, the request is sent with Cache-Control: no-cache

The version on the Greasy Fork webpage is shown correctly with is 3.2.35 after it is just updated using webhook.

However, the responded file is still the old version. // @version 3.2.34

The Last-Modified also refers to the old version rather the update just now. 05 Dec 2023

• As the response suggested, the file is not cached by the browser itself. It is 200 OK. The request itself is also with the no-cache control.

After few minutes of the update

• The script version is updated in Greasy Fork webpage
• The script version in the update.greasyfork.org is updated. (no-cache is implemented)
• BUT there is a cache control issue from the server that, if the cache-control is not specified by the javascript fetch API, it will make the browser to just read the cached copy.

Example Screenshot for Status Code 200 OK (from disk cache)

• This will lead the userscript manager like violentmonkey to show the old version in the install page.
• This can be solved using manual hard loading (ctrl-shift-R), so that it will force the browser to clear the cache and request the fresh copy from update.greasyfork.org

After few hours

• The script version is updated in Greasy Fork webpage
• The script version in the update.greasyfork.org is updated. (with or without no-cache)
• No matter the network request is with no-cache or not, the latest version will be fetched.

Related Issue

• See https://github.com/violentmonkey/violentmonkey/issues/1980

[JasonBarnabe]

After an update, there is a cron job that runs every minute to ensure the cached latest code is cleared on every server. If you request the code within a minute of an update, there's a good chance you will still receive an older version.

Specifically looking at the cache status of the file in your first set of screenshots, I can see that (in UTC times):

• Script was updated 2023-12-10 12:50:06
• New cached file was created 2023-12-10 12:51:23 (the first request after the cache was cleared)

Generally, I don't think this is a problem for normal use. It's not a big deal that there is a potential one minute delay for updates, as you're dealing with hours-long delay for updates anyway due to the frequency of update checks.

If you're doing something programmatic and want to bypass the browser cache, I suggest just adding a timestamp to the URL.

[JasonBarnabe]

Closing per above.

[cyfung1031]

After an update, there is a cron job that runs every minute to ensure the cached latest code is cleared on every server.

I don't understand why you need to do it with an one-minute interval.

There are only two ways to update the script

1. from the greasy fork web
2. from the webhook / regular checking in a fixed interval (auto update)

Both will trigger the adding of @updateURL and @downloadURL

You just need to clear the cache after the addition of @updateURL and @downloadURL There is no need to clear the cache for every one minute.

If you're doing something programmatic and want to bypass the browser cache, I suggest just adding a timestamp to the URL.

I tried. In the old days, I can always get the latest code using https://greasyfork.org/scripts/1-testing/code/XXXXXXX.user.js by replacing the XXXXXXX to a random string.

Now, I cannot find anyway, including adding a timestamp to the URL, to get the latest code after it is just updated.

Now the old url just redirect to the cached url.