Last modified: 2014-02-12 23:52:53 UTC
Hours after yesterday's deployment, Jon reported issues relating to unresponsive sections on en.m.wikipedia.org on Opera Mobile on a Nokia E63. After some debugging, it appears that ResourceLoader is attempting to load outdated resources - in this particular case, it's attempting to load resources that have been moved (their paths have been updated). In the past when we've seen similar issues and have been able to isolate which module was loading incorrect versions of the resource, the problem was solvable by touching a resource from the module on Fenari and then re-syncing it to the cluster. I'm not sure what the way forward is here as the paths for all resources in the problem module ('mobile') have changed. Krinkle suggested in IRC this might be related to a bug in ResourceLoader.
FWIW here's the URL for the improperly cached resource: http://bits.wikimedia.org/en.wikipedia.org/load.php?debug=false&lang=en&modules=mobile%7Cmobile.references&only=scripts&skin=mobile&version=1349820291&*
From #wikimedia-mobile: Krinkle: awjr: jdlrobson: the bug in RL is that max(timestamps(files)) remains the same if an old(er) file is removed from the set. Krinkle 10:56 awjr: jdlrobson: however the reason for it to be rare, is that if a file is removed, in general it is reasonable to assume other files change to accomodate for it. If not, and it was standalone, it should've been in its own module 10:57 awjr Krinkle: there was a wholesale updating of paths for resources 10:57 Krinkle awjr: No, other than making sure the timestamp does increase, by making an insignificant change to other files awjr: updating of paths is not a problem, rl is fine with that 10:57 awjr Krinkle: ok, so even touching one of the new files should do the trick? 10:58 Krinkle awjr: yes. 10:58 awjr Krinkle: great thanks. After the MW general deployment is over, I'll touch one of the resource files and try re-sync'ing
I touched javascripts/common/mf-application.js and sync-file'd from Fenari. This appears to have resolved the issue. This seems to have been a symptom of bug #37812
