Hi,
I've recently seen some complaints from 2 users located in the same country that it takes about half a day for the Javascript changes to propagate. Users from different countries but similar user rights don't seem to have this problem.
Is it possible to have different cache invalidation rules for different countries? If not, what else could cause this behavior?
Thanks, Strainu
Its possible that different cache clusters have different versions of a cached file.
Different ways of loading js have different cache characteristics (e.g. some have much less purging) so it can depend a bit on method. Its also possible that one datacenter missed a cache purge the others did not, however in modern times this is a much more reliable process so unlikely.
-- Bawolff
On Sunday, April 3, 2022, Strainu strainu10@gmail.com wrote:
Hi,
I've recently seen some complaints from 2 users located in the same country that it takes about half a day for the Javascript changes to propagate. Users from different countries but similar user rights don't seem to have this problem.
Is it possible to have different cache invalidation rules for different countries? If not, what else could cause this behavior?
Thanks, Strainu
On Sun, 3 Apr 2022, at 17:57, Strainu wrote:
Hi,
I've recently seen some complaints from 2 users located in the same country that it takes about half a day for the Javascript changes to propagate. Users from different countries but similar user rights don't seem to have this problem.
Is it possible to have different cache invalidation rules for different countries? If not, what else could cause this behavior?
It depends on what kind of changes and to what piece of JavaScript code.
My guess would be that this is a change not to deployed software or gadgets or site scripts, but a user script. And that the user script is loaded by URL via importScriptURI or mw.loader.load. And that the URL is non-standard (e.g. not exactly /w/index.php?title=..&action=raw&ctype=text/javascript, but with other parameters or different order or different encoding). This means that it is not purged on edits.
In that case, it will stay cached. It might then be that someone near one data center is lucky that the URL is not used there before and sees no cache. Or that near another data center the URL is not popular enough to stay in the CDN and thus falls out before the 7 day expiry despite no observed edit or purge.
To know for sure, I would need to see the specific script edit and how the script is loaded.
-- Krinkle
Thank you for your responses folks. The script is a gaget [1], loaded and unloaded through the preferences.
Regards, Strainu
[1] https://ro.wikipedia.org/wiki/MediaWiki:Gadget-wikidata-description.js
În lun., 4 apr. 2022 la 04:20, Krinkle krinkle@fastmail.com a scris:
On Sun, 3 Apr 2022, at 17:57, Strainu wrote:
Hi,
I've recently seen some complaints from 2 users located in the same country that it takes about half a day for the Javascript changes to propagate. Users from different countries but similar user rights don't seem to have this problem.
Is it possible to have different cache invalidation rules for different countries? If not, what else could cause this behavior?
It depends on what kind of changes and to what piece of JavaScript code.
My guess would be that this is a change not to deployed software or gadgets or site scripts, but a user script. And that the user script is loaded by URL via importScriptURI or mw.loader.load. And that the URL is non-standard (e.g. not exactly /w/index.php?title=..&action=raw&ctype=text/javascript, but with other parameters or different order or different encoding). This means that it is not purged on edits.
In that case, it will stay cached. It might then be that someone near one data center is lucky that the URL is not used there before and sees no cache. Or that near another data center the URL is not popular enough to stay in the CDN and thus falls out before the 7 day expiry despite no observed edit or purge.
To know for sure, I would need to see the specific script edit and how the script is loaded.
-- Krinkle
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org To unsubscribe send an email to wikitech-l-leave@lists.wikimedia.org https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
On Mon, 4 Apr 2022, at 10:12, Strainu wrote:
Thank you for your responses folks. The script is a gaget [1], loaded and unloaded through the preferences.
Regards, Strainu
[1] https://ro.wikipedia.org/wiki/MediaWiki:Gadget-wikidata-description.js
This page has a history of two revisions, both 25 Mar, about 10 minutes apart.
Is the reported issue that its last edit [1] was seemingly not applied for some editors? E.g. they kept getting the previous version with the getElementByID error?
-- Krinkle
[1] https://ro.wikipedia.org/w/index.php?title=MediaWiki%3AGadget-wikidata-descr...
În mie., 6 apr. 2022 la 22:55, Krinkle krinkle@fastmail.com a scris:
On Mon, 4 Apr 2022, at 10:12, Strainu wrote:
Thank you for your responses folks. The script is a gaget [1], loaded and unloaded through the preferences.
Regards, Strainu
[1] https://ro.wikipedia.org/wiki/MediaWiki:Gadget-wikidata-description.js
This page has a history of two revisions, both 25 Mar, about 10 minutes apart.
Is the reported issue that its last edit [1] was seemingly not applied for some editors? E.g. they kept getting the previous version with the getElementByID error?
No, the issue is that the users would disable the gadget and it would still be enabled after 12h.
Strainu
-- Krinkle
[1] https://ro.wikipedia.org/w/index.php?title=MediaWiki%3AGadget-wikidata-descr... _______________________________________________ Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org To unsubscribe send an email to wikitech-l-leave@lists.wikimedia.org https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
No, the issue is that the users would disable the gadget and it would still be enabled after 12h.
Were they enabling it by putting directly into User:.../common.js or through Special:Preferences? The former might be subject to weird caching but I always assumed it was properly invalidated on changes. If using Special:Preferences, that sounds like a more serious bug and it would be good to know.
wikitech-l@lists.wikimedia.org