Page MenuHomePhabricator

Unversioned module requests (e.g. "site") should not take 5 minutes to roll over
Closed, DeclinedPublic

Description

I have made a edit to monobook.js on dewiki [0]. This change was not directly visible on my client. I have reload the page, logged off, cleared cache and login, nothing helps. After a time of 5 minutes it takes effect and I saw my suggested fix to the editsection placements on dewiki.

It is possible, that the recache on edit does not load the new script from master? Instead the old one goes into the cache. After 5 minutes (the default cache time for this) the new script is bundled into the cache (maybe also from slave, but no slave is more than 5 minutes behind master) and all will work.

This is a bad situation, when the first edit will introduce a javascript error and you recognize this after the 5 minutes, you fix to the javascript takes also 5 minutes to go to all clients. This means 5 minutes of javascript errors on the whole site, very bad.

[0] https://de.wikipedia.org/w/index.php?title=MediaWiki:Monobook.js&diff=prev&oldid=118091021


Version: 1.22.0
Severity: normal

Details

Reference
bz47941

Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 1:28 AM
bzimport set Reference to bz47941.
bzimport added a subscriber: Unknown Object (MLST).
Krinkle renamed this task from Change to site js not directly visible on client side - recache on edit does not load from master? to Unversioned module requests (e.g. "site") should not take 5 minutes to roll over.Apr 28 2015, 5:52 PM
Krinkle set Security to None.
Krinkle removed a subscriber: Unknown Object (MLST).
Krinkle closed this task as Declined.Apr 28 2015, 5:59 PM
Krinkle claimed this task.

At the moment the duration of 5 minutes is by design. This is not related to master-slave database replication, but has everything to do with HTTP caching on bits.wikimedia.org and inside ResourceLoader.

Versioned requests generated by mw.loader.load are cached for 31+ days and appear to roll over instantly when the new timestamp is available.

Versioned requests for user modules also roll over instantly as the version number is embedded in the page html.

Unversioned requests such as for CSS-only modules (not dependent on JavaScript) are embedded in the page html. Since we don't want to invalidate the cache of all Wikipedia articles globally whenever a skin or site module changes, the request here has no version timestamp included. As such there is no way for the browser to know when these have changed. While this group of modules is limited, the Skin and Site modules are among them. The 5 minute cache is the best compromise we found at the time, and a big leap forward compared to the 30 day Squid cache we used to have for site modules.

However, even after T96797 is fixed and we version these, the startup timestamp manifest is still cached for 5 minutes. This seems like a reasonable amount of time to roll out to all users of an entire wiki.

We may be able to revisit this if we support ESI partials in our caching layer. Thus allowing us to embed versioned content inside regular article responses that can explicitly refreshed at any time.