From InitialSettings.php, for reference:

'wmgUseLiquidThreads' => [
//
// !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
// Do not enable this on new wikis.
// !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
//
	'default' => false,
	'enwikinews' => true, // Per T23956 -- Andrew 2009-02-09
	'enwiktionary' => true, // T25417 -- ariel 2010-16-05
	'huwiki' => true, // T24909 -- Andrew 2010-09-06
	'ptwikibooks' => true, // T26143 -- Andrew 2010-08-16
	'svwikisource' => true, // T25220 -- Andrew 2010-08-28
],

Backport deployed for improved logging on wmf.29 (currently on test.wikipedia.org): https://gerrit.wikimedia.org/r/c/mediawiki/core/+/662065

No activity since 2019, nothing relevant in the logs for a year. Closing for now. Please reopen if it happens again.

I outlined a way to avoid this data corruption here: T263301#6487019.

Here is another report of this kind of data corruption, caused by a different error condition: T198177: Due to PHP fatal, a new version upload overwrote a file (the original is gone)

Next steps:

Since we are preferring OAuth for the REST API, and requiring a CSRF token for cookie-based auth is erring on the safe side and already working, let's just keep things as they are for now. If this turns out to be a probelm, we can bring back this ticket.

Same cause as T273805, the patch was merged yesterday. Do you think it needs a backlport? https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Collection/+/659074

Ok, I was able to reproduce this by inserting sleep(1) between the two calls to getParserOutput() in testOldRevisionUseCached(). Seems like something is a bit too eager to expire...

In T253078#6568524, @DannyS712 wrote:

@eprodromou is it okay to move forward with this using ObjectFactory specs for DI? This has been in "Tech Planning Review" since May

Hm, the error message indicates that something is dropped from the fake parser cache used by the tests. Which shouldn't be possible, since it's backed by a HashBagOStuff. Unless a very low expiry time is set, and the test is running very slowly. But the expiry time should be one hour, I can't imagine it running that slowly...

@Lucas_Werkmeister_WMDE wrote:

so for a RevisionRecord belonging to a non-local wiki, calling getId() without arguments will now trigger a call to wfDeprecatedMsg(). But wfDeprecatedMsg() is apparently enough to make unit tests fail, and also cause warnings to be displayed in the page output, so I assume it counts as hard deprecation. Shouldn’t there have been a period of soft deprecation in between?

I'm confused - does this happen in production? Or does it make tests fail on the extension repos? If so, which tests?

The fact that's it's flaky at this rate shows there's logic problem with the test or the code it's testing. Since there's no fix upto now I don't see any harm in halting it, it can simply be reenabled anytime the issue is fixed. But leaving it hoping the issue to simply go away is wasting people's time.

I suspect that this is caused by an empty (or otherwise invalid) user name in the revision history somewhere. I wrote a fix for a similar issue last week, see T232451: ParameterAssertionException: "Bad value for parameter $title: invalid name" (affects actions info, history, diff).

Could perhaps be caused by this: T264391: FeaturedFeedChannel must not contain a User object, since it cannot be serialized safely.

@Urbanecm Thank you!