Next is the prod (or beta) config enabling.
Found the faulty input. Happens a few times ever hour it seems.
Local debugging showed me that the case of lazy-loaded modules inserting additional styles is fairly rare (and unavoidable anyway).
Thu, Sep 21
Note that our core unit tests are currently passing on Travis CI: https://travis-ci.org/wikimedia/mediawiki
Wed, Sep 20
Existing abstract lock managers in MediaWiki core:
I asked @aaron about an example use for this interface, in preparation for the IRC meeting tonight..
<Krinkle> what would be a good example in core or an extension that would make use of this interface (e.g. something that currently does something less nice)
<AaronSchulz> I think the edit stash locks that use always GET_LOCK atm. This is less flexible and is slower for postgres and sqlite since that just does a looping check.
<AaronSchulz> the getScopedLock calls in AuthManager/MessageCache too
<AaronSchulz> ChronologyProtector too
This seems to have resolved itself.
Tue, Sep 19
@FO-nTTaX I hope the above helps you solve the problem (by removing scripts/jquery.min.js from the skins.liquiflow module definition in LiquiFlow). I'll close this task as invalid given it isn't a problem in MediaWiki or ResourceLoader.
@FO-nTTaX I was able to reproduce it, and again with a breakpoint at the offending line in mediawiki.page.gallery.
The MessageBlobStoreTest intentionally doesn't depend on your local installs' cache configuration (which might be CACHE_NONE / EmptyBagOStuff). Instead, the test mocks this in favour of a simple in-memory cache (HashBagOStuff). I don't see how this could end up wiping a key without it explicitly being cleared.
I/m curious whether it would make sense to consider merging WMF's rpc/runJobs and core's SpecialRunJobs.
Mon, Sep 18
I reproduced the issue and notice two things:
The tool home page now shows a short page with link to Documentation instead of automatic redirect.