"Click to force an update" button doesn't update recently updated filter lists

[injust]

Prerequisites

• I verified that this is not a filter list issue. Report any issues with filter lists or broken website functionality in the uAssets issue tracker.
• This is NOT a YouTube, Facebook or Twitch report. These sites MUST be reported by clicking their respective links.
• This is not a support issue or a question. For support, questions, or help, visit /r/uBlockOrigin.
• I performed a cursory search of the issue tracker to avoid opening a duplicate issue.
• The issue is not present after disabling uBO in the browser.
• I checked the documentation to understand that the issue I am reporting is not normal behavior.

I tried to reproduce the issue when...

• uBO is the only extension.
• uBO uses default lists and settings.
• using a new, unmodified browser profile.

Description

The "Click to force an update" button doesn't actually update a custom filter list if it was already updated recently (1-2 minutes ago). If I visit the filter list URL directly in my browser, I see the newest version, but uBlock Origin still uses the old version.

Instead, I have to delete the filter list and re-import it.

A specific URL where the issue occurs.

N/A

Steps to Reproduce

These steps are a bit convoluted. You may be able to reproduce by hosting a filter list on somewhere without caching, updating it in uBlock Origin, editing it, and updating it again.

1. Host a filter list on GitHub Gist
2. Import it as a custom filter list using the non-version specific URL (i.e. https://gist.github.com/[user]/[hash]/raw/[filename].txt)
3. Press "Click to force an update"
4. Edit the Gist
5. Visit the URL in your browser (you will be served the old version because of GitHub's caching)
6. Connect to a VPN (to bypass GitHub's caching)
7. Repeat 5) (you should see the newest version of the Gist)
8. Press "Click to force an update"

Expected behavior

uBlock Origin actually updates a filter list when you press "Click to force an update"

Actual behavior

"Click to force an update" does nothing. The spinner spins, but the fetched filter list is still the old version.

uBO version

1.67.0

Browser name and version

Chrome 142.0.7444.162

Operating System and version

macOS Sequoia 15.7.2

[gorhill]

Press shift key when you click to bypass the browser cache.

[injust]

Seems like that works, thank you!

Maybe it should be documented in the tooltip, or on https://github.com/gorhill/ublock/wiki/Dashboard:-Filter-lists. I found shift mentioned there, but only in relation to the removed "Purge all caches" button.

[freezer2022]

• (injust): I performed a cursory search of the issue tracker to avoid opening a duplicate issue.

A duplicate of (automatic way):

• Forcing update of imported filter list doesn't update for an hour or so #3715
• There is a problem with custom rule list updates #1656

As for the manual way (with shift):

injust: Maybe it should be documented on https://github.com/gorhill/ublock/wiki/Dashboard:-Filter-lists
injust: I found shift mentioned there, but only in relation to the removed "Purge all caches" button.

Just below that, there is a link to a discussion, which explains that maybe it stays undocumented on purpose, to not be abused:

• Remove "Purge all caches" button #3022 (reply in thread)

but on the other hand, the automatic way (updateAssetBypassBrowserCache) is documented, therefore it seems that there exists some inconsistency in documentation: the automatic way is documented, while the manual way not, despite the both options are for advanced users, although the automatic way requires to enable https://github.com/gorhill/uBlock/wiki/Advanced-settings, while the manual way not, maybe that's the difference why the manual way stays undocumented (on purpose).

[injust]

Hmm, I have updateAssetBypassBrowserCache set to true but still ran into the same problem just now.

[krystian3w]

Gist may still have a 2-minute delay in the cache, and MS is unlikely to change this (If your gist is public, consider migrating to a public repository - due to the fact that repositories have an unstable authorization key parameter value, a private repo is more private than a non-public gist).

[injust]

Gist may still have a 2-minute delay in the cache

Which is why I connected to a VPN (to avoid hitting the regional cache). On the VPN, the same URL (https://gist.github.com/[user]/[hash]/raw/[filename].txt) gives me the latest version of the Gist. Which is why I think this might be a uBlock issue.

[freezer2022]

injust: (...) Which is why I think this might be a uBlock issue.

Perhaps, but perhaps not, as using VPN still might not always work:
https://github.com/orgs/community/discussions/46691#discussioncomment-4944177

[injust]

Perhaps, but perhaps not, as using VPN still might not always work:

I don't think that's relevant here. The key thing is that my browser gets the latest version when I visit the URL directly.

[freezer2022]

And I "think" it is, have you even read / understand what I linked to, before carelessly throwing it in the trash:

https://github.com/orgs/community/discussions/46691#discussioncomment-4944410 : I tested it as well and I can confirm that the raw file is IP dependant, but for some reasons I still get the old version when reading it through a script, even if I'm using a "working" IP address.

Now if you just replace a word "script" with a word "uBlock", you will get the same / similar case like your. And sure, that might turn out to be still a problem in a script / ublock, but at least what I linked IS relevant / related, because I provided same / similar case, which at least means that uBlock is not alone here with it's issue.

another possibility:

https://github.com/orgs/community/discussions/46691#discussioncomment-4944615 :
However, it varies even then, had a few times the current version, later again the old version.

Which means that your issue might turn out to be a pure randomness, means you had a luck when fetching from browser, and not when fetching from uBlock. Unless you tried 10 or 20 times in a row in both browser and uBlock to rule out a pure randomness as a possibility / factor. Did you? At least you did not inform us about how many times you tried. As in the past there happened sometimes annoying / random issues related to uBlock, which required trying 10 or 20 times before realising that the issue was different than what it was looking like, and was caused by a random factor, regardless of whether the issues was caused by uBlock or not.