Page MenuHomePhabricator

Argument 1 passed to MediaWiki\Extension\Translate\PageTranslation\ParserOutput::sourcePageTextForRendering() must be an instance of Language, instance of StubUserLang given, called in /srv/mediawiki/php-1.36.0-wmf.36/extensions/Translate/tag/PageTranslationHooks.php on line 53
Closed, ResolvedPublicPRODUCTION ERROR

Description

Error

MediaWiki version: 1.36.0-wmf.36

message
Argument 1 passed to MediaWiki\Extension\Translate\PageTranslation\ParserOutput::sourcePageTextForRendering() must be an instance of Language, instance of StubUserLang given, called in /srv/mediawiki/php-1.36.0-wmf.36/extensions/Translate/tag/PageTranslationHooks.php on line 53

Impact

Notes

Apparently solely on metawiki and happening when people submit a page.

Details

Request URL
https://meta.wikimedia.org/w/index.php?title=Template:AWC_Header&action=submit
Stack Trace
exception.trace
from /srv/mediawiki/php-1.36.0-wmf.36/extensions/Translate/src/PageTranslation/ParserOutput.php(62)
#0 /srv/mediawiki/php-1.36.0-wmf.36/extensions/Translate/tag/PageTranslationHooks.php(53): MediaWiki\Extension\Translate\PageTranslation\ParserOutput->sourcePageTextForRendering(StubUserLang)
#1 /srv/mediawiki/php-1.36.0-wmf.36/includes/HookContainer/HookContainer.php(330): PageTranslationHooks::renderTagPage(Parser, string, StripState)
#2 /srv/mediawiki/php-1.36.0-wmf.36/includes/HookContainer/HookContainer.php(137): MediaWiki\HookContainer\HookContainer->callLegacyHook(string, array, array, array)
#3 /srv/mediawiki/php-1.36.0-wmf.36/includes/HookContainer/HookRunner.php(2925): MediaWiki\HookContainer\HookContainer->run(string, array)
#4 /srv/mediawiki/php-1.36.0-wmf.36/includes/parser/Parser.php(1532): MediaWiki\HookContainer\HookRunner->onParserBeforeInternalParse(Parser, string, StripState)
#5 /srv/mediawiki/php-1.36.0-wmf.36/includes/parser/Parser.php(639): Parser->internalParse(string)
#6 /srv/mediawiki/php-1.36.0-wmf.36/includes/content/WikitextContent.php(375): Parser->parse(string, Title, ParserOptions, boolean, boolean, NULL)
#7 /srv/mediawiki/php-1.36.0-wmf.36/includes/content/AbstractContent.php(591): WikitextContent->fillParserOutput(Title, NULL, ParserOptions, boolean, ParserOutput)
#8 /srv/mediawiki/php-1.36.0-wmf.36/includes/content/ContentHandler.php(908): AbstractContent->getParserOutput(Title, NULL, ParserOptions, boolean)
#9 /srv/mediawiki/php-1.36.0-wmf.36/includes/content/ContentHandler.php(947): ContentHandler->getChangeType(WikitextContent, WikitextContent, integer)
#10 /srv/mediawiki/php-1.36.0-wmf.36/includes/Storage/PageUpdater.php(651): ContentHandler->getAutosummary(WikitextContent, WikitextContent, integer)
#11 /srv/mediawiki/php-1.36.0-wmf.36/includes/Storage/PageUpdater.php(809): MediaWiki\Storage\PageUpdater->makeAutoSummary(integer)
#12 /srv/mediawiki/php-1.36.0-wmf.36/includes/page/WikiPage.php(2217): MediaWiki\Storage\PageUpdater->saveRevision(CommentStoreComment, integer)
#13 /srv/mediawiki/php-1.36.0-wmf.36/includes/page/WikiPage.php(2071): WikiPage->doUserEditContent(WikitextContent, User, CommentStoreComment, integer, boolean, array, integer)
#14 /srv/mediawiki/php-1.36.0-wmf.36/includes/EditPage.php(2357): WikiPage->doEditContent(WikitextContent, string, integer, boolean, User, string, array, integer)
#15 /srv/mediawiki/php-1.36.0-wmf.36/includes/EditPage.php(1690): EditPage->internalAttemptSave(array, boolean)
#16 /srv/mediawiki/php-1.36.0-wmf.36/includes/EditPage.php(665): EditPage->attemptSave(array)
#17 /srv/mediawiki/php-1.36.0-wmf.36/includes/actions/EditAction.php(71): EditPage->edit()
#18 /srv/mediawiki/php-1.36.0-wmf.36/includes/actions/SubmitAction.php(38): EditAction->show()
#19 /srv/mediawiki/php-1.36.0-wmf.36/includes/MediaWiki.php(531): SubmitAction->show()
#20 /srv/mediawiki/php-1.36.0-wmf.36/includes/MediaWiki.php(315): MediaWiki->performAction(Article, Title)
#21 /srv/mediawiki/php-1.36.0-wmf.36/includes/MediaWiki.php(925): MediaWiki->performRequest()
#22 /srv/mediawiki/php-1.36.0-wmf.36/includes/MediaWiki.php(547): MediaWiki->main()
#23 /srv/mediawiki/php-1.36.0-wmf.36/index.php(53): MediaWiki->run()
#24 /srv/mediawiki/php-1.36.0-wmf.36/index.php(46): wfIndexMain()
#25 /srv/mediawiki/w/index.php(3): require(string)
#26 {main}

Event Timeline

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

hashar triaged this task as Unbreak Now! priority.Thu, Mar 25, 7:48 PM

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 ) {

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_.

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!

  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?

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

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.

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

Merged

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)

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)

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.

Urbanecm claimed this task.

Closing as this very issue was resolved by reverting the problematic core patch. As for prevention of similar issues, we can look into T244383, which is a different task. We also should redo what that patch did via a different approach, which is tracked in T266067. Since I don’t see an actionable to do here, I’m closing this one.

Anyone should feel free to reopen this if they see an actionable that should be tracked here. If someone does it, please don’t forget to declassify as a train blocker, since it should no longer block the train.