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.