On Mon, Dec 9, 2013 at 2:58 PM, Ryan Kaldari rkaldari@wikimedia.org wrote:
I am somewhat concerned about the implications for JS debugging here. Debugging JS problems with the live sites is already pretty complicated:
- debug=true won't reproduce some bugs (usually race condition related)
Yeah, debug mode sucks. I think we need to think it over.
- Sometimes old code gets cached with the new cache-busting timestamp
(due
to a race condition between bits and apache at deployment)
Fixed in https://gerrit.wikimedia.org/r/#/c/90541/ and < https://gerrit.wikimedia.org/r/#/c/90541/%3E.
- Sometimes the cache servers cache different code for the same URL, i.e.
one cache server will have one version and another cache server will have another
I haven't seen this happen.
- In some cases ResourceLoader doesn't change the cache-busting timestamp
(if you just remove files or add older files to a module)
Timo fixed this in https://gerrit.wikimedia.org/r/#/c/90541/.
- You always have to face the 5 Minutes of Doom (how frequently
ResourceLoader rebuilds the startup manifest)
Well, yes, there's that.
And that's not even mentioning client-side caching. Shouldn't we work on fixing or mitigating some of these issues before we make JS debugging even more complicated?
I don't entirely agree. Modules in localStorage are versioned in the same way URLs are versioned, and to date there no bugs with module storage cache management have been reported, despite the fact that module storage is now used across all projects.