On Mon, Dec 9, 2013 at 2:58 PM, Ryan Kaldari <rkaldari(a)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:
1. debug=true won't reproduce some bugs (usually race condition related)
Yeah, debug mode sucks. I think we need to think it over.
2. 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/>gt;.
> 3. 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.
> 4. 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/>.
> 5. 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.