https://bugzilla.wikimedia.org/show_bug.cgi?id=45877
Web browser: ---
Bug ID: 45877
Summary: ResourceLoader caches missing module for many minutes
after it's available
Product: MediaWiki
Version: 1.21-git
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: Unprioritized
Component: ResourceLoader
Assignee: [email protected]
Reporter: [email protected]
CC: [email protected], [email protected],
[email protected], [email protected]
Classification: Unclassified
Mobile Platform: ---
E3 deployed several extensions with changed modules today. GettingStarted had a
new RL module 'ext.gettingstarted.openTask' for a new JS file
resources/ext.gettingstarted.openTask.js. scap finished 4:19PDT [00:19:44]
50 minutes after scap finished I visited a page that should have had the new
module, but didn't. mw.loader.getState( 'resources/ext.gettingstarted' )
reported "missing". Shift-reload of the page didn't help; requesting just the
bits URL that included this module [1] also reported it "missing"[2].
Modifying the version in the query string to a later time or requesting just
the ext.gettingstarted.openTask module worked fine.
My hypothesis: during scap, some user requested a page that ran the new PHP
code that adds the new module, so her browser made the request to
bits.wikimedia.org for modules including the new module. At that time the bits
server didn't yet have the JS file, so the server response reports "missing".
But then RL happily caches that response for X minutes, where X is a long time,
well over 50 minutes.
The missing module continued for about 10 more minutes, until the same URL
worked.[3] The working request reported a modified time of Thu 07 Mar 2013
04:07:51 PM PST (I think 00:07:51 UTC, which matches the version= on the end of
the bits URL.
The a-m-c times of the ext.openTask.js file according to stat(1) are
Access: 2013-03-08 00:08:12.857544926 +0000
Modify: 2013-03-07 21:49:43.000000000 +0000
Change: 2013-03-08 00:08:12.857544926 +0000
the same as the other files in the module that existed before this deploy.
Is the workaround to avoid these damaging situations to touch every JS and CSS
file that one deploys before running scap?
This might be a dupe of bug 37812 , "Module cache should be invalidated (newer
timestamp) when lesser old items are removed or added (scripts, style,
messages)"
[1] The request with missing module:
https://bits.wikimedia.org/en.wikipedia.org/load.php?debug=false&lang=en&modules=ext.Experiments.lib|ext.UserBuckets%2CeventLogging%2CmarkAsHelpful%2CpostEdit|ext.articleFeedbackv5.startup|ext.gadget.DRN-wizard%2CHotCat%2CReferenceTooltips%2Ccharinsert%2CmySandbox%2Cteahouse|ext.gettingstarted.openTask|jquery.articleFeedbackv5.verify|jquery.autoEllipsis%2CcheckboxShiftClick%2CclickTracking%2CdelayedBind%2Chidpi%2ChighlightText%2Cjson%2CmakeCollapsible%2Cmw-jump%2Cplaceholder%2Csuggestions%2CtabIndex|mediawiki.Title%2CUri%2Capi%2Chidpi%2CsearchSuggest%2Cuser|mediawiki.api.watch|mediawiki.page.ready|mediawiki.page.watch.ajax|mobile.desktop|mw.MwEmbedSupport.style|mw.PopUpMediaTransform|schema.GettingStarted&skin=vector&version=20130308T000751Z&*
[2] The end of the (jsbeautify'd) response for this URL was:
}, {}, {});
mw.loader.state({
"ext.gettingstarted.openTask": "missing"
});
/* cache key:
enwiki:resourceloader:filter:minify-js:7:3e6c3b5e8a0b731930af1060b6ab62b6 */
[3] The identical URL request when it starting working returned a last line of:
/* cache key:
enwiki:resourceloader:filter:minify-js:7:03dcfbab169aa00f66478e647270d340 */
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
You are watching all bug changes.
_______________________________________________
Wikibugs-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
