https://bugzilla.wikimedia.org/show_bug.cgi?id=45877
Krinkle <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|DUPLICATE |--- --- Comment #3 from Krinkle <[email protected]> --- (In reply to comment #1) > (In reply to comment #0) > > Is the workaround to avoid these damaging situations to touch every JS and > > CSS > > file that one deploys before running scap? > > Isn't touching startup.js enough IIRC? Yeah, because that will (as a side-effect) invalidate the startup module request entirely (not just the manifest) and when it re-calculates the manifest it will see that the module has in fact changed and the next user getting the startup module will get a higher timestamp and thus a different bits url and thus the working code. However, this may not be working because of what you think. Let me clarify just in case. The timestamp the module gets after touching startup.js is not related to the time you touch startup.js. That just forces resourceloader to re-check the timestamps of the files in the module (which you didn't touch by touching startup.js). The timestamp will still be higher because, as Matthew correctly described, the previous time resourceloader was asked to check the timestamp (due to that unfortunate visitor during scap) some of the files weren't there yet. (In reply to comment #2) > Yep, sounds like a dupe. Thank you for tracking it down. > > *** This bug has been marked as a duplicate of bug 37812 *** No, this is not a dupe of that bug. bug 37812 is about the case where you properly deploy a change but the timestamp (no matter how many times to invalidate the startup manifest) does not change because none of the components resourceloader checks for have changed. bug 37812 happens when the change you make only involves removing older files from the array, or adding new files that were modified longer ago, causing the max() to still be the same. This bug (bug 45877) is about the race condition where one server is already embedding requests urls in the page (or mw.loader.load calls) while the module in question is not yet available on the apache server that the request will be made to. e.g. en.wikipedia.org --> srv123 @r12 --> outputs html mw.loader.load('foo') -> bits.wikimedia.org --> srv214 @r11 --> mw.loader.state('foo', 'missing'); Where that exact url (with that timestamp) will get cached for 30 days. Not it wont be broken for 30 days because the startup manifest en.wikipedia.org requests context work with (from bits) will be rebuilt every 5 minutes. I'm not sure what the proper solution is for this problem. Perhaps syncing to bits firts, though that might bring the opposite problem, which is likely less visible, but might be problematic also. -- 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
