TLDR: Previously, PHPUnit enabled all caches except WANObjectCache. This is now enabled as
well. If you encounter a new test failure this week on an extension repo that is not
covered by the automated "wmf CI gate", then that may be the reason. This could
point to a genuine bug in your code. However, you can choose to turn of all caching layers
in the relevant test cases by calling $this->setMainCache( CACHE_NONE ).
Hi,
MediaWiki provides broudly four layers of object caching
<https://www.mediawiki.org/wiki/Object_cache>, that are individually configurable
(to optimise large wiki farms like Wikipedia). Each of these auto-configures themselves or
falls back to $wgMainCacheType
<https://doc.wikimedia.org/mediawiki-core/master/php/classMediaWiki_1_1MainConfigSchema.html#a0b3d0535aa2fc03327944280797b1c54>,
thus in practice you don't need to be aware of their differing backends. They have a
simple unified interface: BagOStuff.
In our PHPUnit context, we set each layer to 'hash' (for HashBagOStuff) which
represents an in-memory cache that we automatically reset between each test and each data
set. In addition to the four levels of caching, this therefore also ensures realistic
caching behaviour during your tests for services such as ParserCache, MessageCache,
SessionStore, MainStash, etc.
For example, your extension might have a test that asserts "no database queries"
made during a cache hit, or it might assert that if an edit is made the same value is
returned as before, and then you call your code's purge method, and assert the updated
value.
By default and during local development, (other) CI jobs, beta cluster, and production -
WANObjectCache is explicitly a wrapper for the main cache (e.g. Memcached at WMF). It is
never configured separately from the main cache, nor is there any known use case (among
both third parties, WMF, and local development) for doing so.
As of this week, configuring WANObjectCache separately from the "main" cache is
no longer supported. This improves defaults for sysadmins and reduces the number things
one has to get right for optimal performance. It also removes an apparent concept from the
code going forward to ease debugging by not having a level of indirection that doesn't
translate to a specific narrative or purpose.
In dong so, we found one place that does configure the WANCache backend, namely our
PHPUnit config. While expected to override it, it overrode it to wrap the no-op
"none" EmptyBagOStuff instead instead of the in-memory "hash"
HashBagOStuff. This quirky setup was surprising a times to developers and required
numerous tests to copy boilerplate around in order to opt-in to to the "normal"
cache behaviour that we expect and follow in other cache levels already. The boiler plate
in question was also atypical in that it wasn't covered by our standard ServiceWiring
and its automatic resets (the main cache is now recognised an injectable internal
service).
Our shared "wmf CI gate" job identified two extensions where this was relied
upon, and I've updated those before making the change
<https://gerrit.wikimedia.org/r/c/mediawiki/core/+/889244> (example 1
<https://gerrit.wikimedia.org/r/c/mediawiki/extensions/GlobalPreferences/+/894115>,
and example 2
<https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/894228>).
If you encounter a new test failure this week on an extension repo that is not covered by
the CI gate, then this may be the reason. Tests that fail with caching enabled, may expose
a bug in the underlying code (e.g. after a cache it should probably not use the cache for
subsequent reads of the same data, unless it is expected that it will be stale), or may
reflect that the code (or the test) is missing a call to your "purge" method, or
that a service reset is needed if the test is meant to reflect what a subsequent web
request would see, etc. You can (temporarily or not) choose to turn of all caching layers
in the relevant test cases by calling $this->setMainCache( CACHE_NONE ). Example
1-line patch
<https://gerrit.wikimedia.org/r/c/mediawiki/extensions/GlobalPreferences/+/894115>.
--
Timo Tijhof
Performance Team,
Wikimedia Foundation.