arichards at wikimedia
Dec 4, 2012, 9:29 AM
Post #2 of 6
On Tue, Dec 4, 2012 at 10:06 AM, Andre Klapper <aklapper [at] wikimedia>wrote:
Re: the skin change in 1.21wmf5, display breakage, & fix retrospective, again
[In reply to]
> After Sumana's summary of the wmf5 phase2 deployment (last Wednesday) at
> we ran into similar issues again yesterday night when deploying to
> English Wikipedia (phase3).
> According to Ryan in bug 42452 , this time "The problem seems to be that
> ResourceLoader isn't delivering the updated CSS." Some minutes later
> Ryan "touched and synced the startup.js and
> ext.vector.collapsibleNav.css files. Seems to be working correctly now."
This seems to be a not-that-uncommon behavior with resources - at least it
has been for deployments of MobileFrontend. We believed it was symptomatic
of this bug: https://bugzilla.wikimedia.org/show_bug.cgi?id=37812, but we
have also run into similar issues in cases other than what Krinkle explains
in the first comment. It would be nice to get this resolved as it causes
big headaches during deployment.
Still, we have several users that state that after purging their browser
> cache they *still* face issues:
Sounds like resources might be stuck in server-side caches.
> Can anyone shed some light on how affected users can track down and help
> to fix the underlying problems here, if possible?
> What could users try, and which data could they provide?
Have them try loading pages with ?action=purge in the URL and see if the
issue is resolved - that should purge the page from the front-end cache.
Failing that, if adding ?debug=true to the URL generates a properly
formatted page, then ResourceLoader is still trying to load out-of-date
resources. If that's the case, another touch/sync on a file from the stale
resource module might do the trick. I imagine ops or the ResourceLoader
folks might have some other ideas.
Software Engineer, Mobile
Wikitech-l mailing list
Wikitech-l [at] lists