On quick testing, I did not find pages other than this which is failing. On logstash there is a few more. So this only affects certain pages.

T244383: Replace StubUserLang with a better lazy loading mechanism would prevent this from happening. Something is returning $wgLang from Parser:.getTargetLanguage. Most likely from Title::getPageLanguage or Title::getPageViewLanguage via wfGetLangObj.

Work around would be to remove type hints or explicitly unstub in Translate. Better fix would be to fix this in Core (maybe inside parser?) to avoid some other code being the next victim.

Maybe obvious, but this is keeping us from working on the upcoming Tech News issue.

@Johan thanks for reporting editing is broken. That seems to edit a wide range of metawiki page (I guess anything that use Translate) and thus I will rollback the MediaWiki version there.

Change 674961 had a related patch set uploaded (by Hashar; author: Hashar):
[operations/mediawiki-config@master] Revert "group1 wikis to 1.36.0-wmf.36"

https://gerrit.wikimedia.org/r/674961

Change 674961 merged by jenkins-bot:
[operations/mediawiki-config@master] Revert "group1 wikis to 1.36.0-wmf.36"

https://gerrit.wikimedia.org/r/674961

Change 674969 had a related patch set uploaded (by Ammarpad; author: Ammarpad):
[mediawiki/core@master] Ensure Title methods/wfGetLangObj returns Language object

https://gerrit.wikimedia.org/r/674969

Update: I'm unable to reproduce this issue locally. Seems to be something that's specific to meta. This patch: https://gerrit.wikimedia.org/r/674969 should fix the issue and if in case it doesn't we'll go ahead and remove the type hint from the method argument.

public function sourcePageTextForRendering( Language $sourceLanguage ) {

In T278429#6947783, @abi_ wrote:

Update: I'm unable to reproduce this issue locally. Seems to be something that's specific to meta.

One of the things that are Meta-specific (and that shoot us into the foot several times) is https://meta.wikimedia.org/wiki/MediaWiki:Mainpage. Meta's main page is set to Special:MyLanguage/Main_Page, which might explain why a weird language object is being returned :-).

I just managed to both reproduce the bug with mainpage being Special:MyLanguage/something and "fix" (=workaround) it by removing Special:MyLanguage/ from MediaWiki:Mainpage configuration page.

Hope this helps with trying to reproduce it, @abi_.

In T278429#6945136, @Nikerabbit wrote:

T244383: Replace StubUserLang with a better lazy loading mechanism would prevent this from happening. Something is returning $wgLang from Parser:.getTargetLanguage. Most likely from Title::getPageLanguage or Title::getPageViewLanguage via wfGetLangObj.

I looked a bit into what happens, and I confirmed that the mediawiki:Mainpage theory is the correct one. This is the high-level overview of what is happening:

1. PageUpdater calls ContentHandler->getAutosummary, which does not have Title as an argument
2. ContentHandler->getAutosummary calls ContentHandler->getChangeType, which (on line 908) calls parser with $oldImages = $oldContent->getParserOutput( Title::newMainPage(), null, null, false )->getImages(). This is when the parser gets into the play. It tries to parse with main page as the title, which...doesn't work well, since main page is set to Special:MyLanguage/Main_Page.
3. When parser tries to determine the page language, it calls Title::getPageLanguage. Since (see first point) Title is a special page, the if at Title.php:4397 passes, and...returns $wgLang, as @Nikerabbit correctly suspected.

Reverting https://gerrit.wikimedia.org/r/c/mediawiki/core/+/663209 should work, since that patch was introduced in wmf.36.

Adding @matthiasmullie and @Cparle, the patch author/reviewer of 5a0bfa9d, the direct cause of this issue.

Nothing else relies on 5a0bfa9d yet, so this should be a simple revert with no extra impact. LMK if you want me to do so!

In T278429#6948865, @Urbanecm wrote:

1. PageUpdater calls ContentHandler->getAutosummary, which does not have Title as an argument
2. ContentHandler->getAutosummary calls ContentHandler->getChangeType, which (on line 908) calls parser with `$oldImages =

$oldContent->getParserOutput( Title::newMainPage(), null, null, false )->getImages()`. This is when the parser gets into the play. It tries to parse with main page as the title, which...doesn't work well, since main page is set to Special:MyLanguage/Main_Page.

Oh wow - that is super expensive! This will re-parse the old content (though we probably already have it in the parser cache, and the images in the db table), and it parses the new content, even though we'll probably do that again when we save. It also bypasses pool counter.

The difference between the old and the new images is known to LinksUpdater later on. Would it be possible to defer whatever you are trying to do until that point?

If not, would it be possible do do it further up the call stack, in a context where a ParserOutputAccess can be used, so we make use of PoolCounter and ParserCache?

In T278429#6948879, @Urbanecm wrote:

Adding @matthiasmullie and @Cparle, the patch author/reviewer of 5a0bfa9d, the direct cause of this issue.

If I'm reading the code correctly, this has to potential to produce a considerable load spike. Reverting is probably a good idea. Needs a different approach. I tried to outline some ideas above, but I'm not familiar with the actual intent behind this change.

Change 675148 had a related patch set uploaded (by Urbanecm; author: Urbanecm):
[mediawiki/core@master] Revert "Add change tags for media additions/removals"

https://gerrit.wikimedia.org/r/675148

In T278429#6949016, @daniel wrote:

In T278429#6948879, @Urbanecm wrote:

Adding @matthiasmullie and @Cparle, the patch author/reviewer of 5a0bfa9d, the direct cause of this issue.

If I'm reading the code correctly, this has to potential to produce a considerable load spike. Reverting is probably a good idea. Needs a different approach. I tried to outline some ideas above, but I'm not familiar with the actual intent behind this change.

Revert uploaded. If you or @matthiasmullie could merge it, it would be best, and we can backport it to wmf.36 soon.

In T278429#6949069, @Urbanecm wrote:

Revert uploaded. If you or @matthiasmullie could merge it, it would be best, and we can backport it to wmf.36 soon.

Merged

In T278429#6949016, @daniel wrote:

If I'm reading the code correctly, this has to potential to produce a considerable load spike. Reverting is probably a good idea. Needs a different approach. I tried to outline some ideas above, but I'm not familiar with the actual intent behind this change.

Thanks, I will look into those alternative suggestions.
(context is in T266067 - basically: "we want to measure the vectors for how multimedia content gets added to Wikipedia articles - via Visual Editor, direct Wikitext editing, or bots", via intersecting edit tags from those tools with new edit tag that points out changes in media)

In T278429#6949079, @matthiasmullie wrote:

Thanks, I will look into those alternative suggestions.
(context is in T266067 - basically: "we want to measure the vectors for how multimedia content gets added to Wikipedia articles - via Visual Editor, direct Wikitext editing, or bots", via intersecting edit tags from those tools with new edit tag that points out changes in media)

I'd say just do it in LinksUpdate. This would be much easier/nicer if we could use the listener pattern... Hooks are kind of that, but listeners could be simpler / more light weight.

Change 675148 merged by jenkins-bot:
[mediawiki/core@master] Revert "Add change tags for media additions/removals"

https://gerrit.wikimedia.org/r/675148

Change 675149 had a related patch set uploaded (by Urbanecm; author: Urbanecm):
[mediawiki/core@wmf/1.36.0-wmf.36] Revert "Add change tags for media additions/removals"

https://gerrit.wikimedia.org/r/675149

Change 675149 merged by jenkins-bot:
[mediawiki/core@wmf/1.36.0-wmf.36] Revert "Add change tags for media additions/removals"

https://gerrit.wikimedia.org/r/675149

Mentioned in SAL (#wikimedia-operations) [2021-03-26T17:10:52Z] <hashar@deploy1002> Started scap: Revert "Add change tags for media additions/removals" - T266067 T278429

Mentioned in SAL (#wikimedia-operations) [2021-03-26T17:42:32Z] <hashar@deploy1002> Finished scap: Revert "Add change tags for media additions/removals" - T266067 T278429 (duration: 31m 43s)

In T278429#6949079, @matthiasmullie wrote:

Thanks, I will look into those alternative suggestions.
(context is in T266067 - basically: "we want to measure the vectors for how multimedia content gets added to Wikipedia articles - via Visual Editor, direct Wikitext editing, or bots", via intersecting edit tags from those tools with new edit tag that points out changes in media)

I'd say just do it in LinksUpdate. This would be much easier/nicer if we could use the listener pattern... Hooks are kind of that, but listeners could be simpler / more light weight.

Change 674969 merged by jenkins-bot:

[mediawiki/core@master] Document methods that may return StubUserLang instead of Language

https://gerrit.wikimedia.org/r/674969