MediaWiki\Linker\LinkRenderer::makeKnownLink() must implement interface MediaWiki\Linker\LinkTarget, null given on Special:Watchlist
Open, Needs TriagePublic

Description

Watchlist can fail, with reports on fr.wiktionary (https://fr.wiktionary.org/wiki/Sp%C3%A9cial:Liste_de_suivi) or https://de.wikipedia.org/wiki/Spezial:Beobachtungsliste

Root cause

$pageTitle = $rc->getTitle(); in the getDiffHistLinks method can return null, a case not currently handled.

We still need to know what could trigger that and what to print instead.

Stacktrace

/srv/mediawiki/php-1.29.0-wmf.21/includes/linker/LinkRenderer.php:301

Argument 1 passed to MediaWiki\Linker\LinkRenderer::makeKnownLink() must implement interface MediaWiki\Linker\LinkTarget, null given

#0 /srv/mediawiki/php-1.29.0-wmf.21/includes/linker/LinkRenderer.php(301): MWExceptionHandler::handleError(integer, string, string, integer, array, array)
#1 /srv/mediawiki/php-1.29.0-wmf.21/includes/changes/EnhancedChangesList.php(724): MediaWiki\Linker\LinkRenderer->makeKnownLink(NULL, HtmlArmor, array, array)
#2 /srv/mediawiki/php-1.29.0-wmf.21/includes/changes/EnhancedChangesList.php(658): EnhancedChangesList->getDiffHistLinks(RCCacheEntry, array)
#3 /srv/mediawiki/php-1.29.0-wmf.21/includes/changes/EnhancedChangesList.php(742): EnhancedChangesList->recentChangesBlockLine(RCCacheEntry)
#4 /srv/mediawiki/php-1.29.0-wmf.21/includes/changes/EnhancedChangesList.php(106): EnhancedChangesList->recentChangesBlock()
#5 /srv/mediawiki/php-1.29.0-wmf.21/includes/specials/SpecialWatchlist.php(468): EnhancedChangesList->recentChangesLine(RecentChange, NULL, integer)
#6 /srv/mediawiki/php-1.29.0-wmf.21/includes/specialpage/ChangesListSpecialPage.php(1067): SpecialWatchlist->outputChangesList(Wikimedia\Rdbms\ResultWrapper, FormOptions)
#7 /srv/mediawiki/php-1.29.0-wmf.21/includes/specialpage/ChangesListSpecialPage.php(506): ChangesListSpecialPage->webOutput(Wikimedia\Rdbms\ResultWrapper, FormOptions)
#8 /srv/mediawiki/php-1.29.0-wmf.21/includes/specials/SpecialWatchlist.php(92): ChangesListSpecialPage->execute(NULL)
#9 /srv/mediawiki/php-1.29.0-wmf.21/includes/specialpage/SpecialPage.php(522): SpecialWatchlist->execute(NULL)

Example of watchlist causing the issue

https://hastebin.com/uvotahalor.sql (but can't repro)

See also

T143477: null argument passed to LinkRenderer::makeKnownLink()

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptApr 28 2017, 10:04 AM
Aklapper renamed this task from Viewing my watchlist returns a blank page or a Wikimedia error to Viewing my watchlist (~5000 entries) returns a blank page or an HTTP 503 error.Apr 28 2017, 1:07 PM

I wonder if this is because of codfw or a mw deploy?

If I deactivate "Hide page categorisation" in my watchlist preferences, the page is correctly displayed. It goes back to blank if I reactivate the parameter.

Note that I follow some very big categories (e.g. https://fr.wiktionary.org/wiki/Cat%C3%A9gorie:fran%C3%A7ais), so that could be a cause, but it did work up until now.

Aklapper renamed this task from Viewing my watchlist (~5000 entries) returns a blank page or an HTTP 503 error to Viewing my watchlist (~5000 entries) returns a blank page or an HTTP 503 error when "Hide: Page categorisation" is activated.Apr 28 2017, 4:06 PM

Happened for me at English Wikisource on Tuesday following code roll out. I can identify it down to one category being the problem

https://en.wikisource.org/wiki/special:permalink/6781615#Watchlist_issues_anyone.3F

In the end I identified as one specific category that was problematic in association with setting to "not hide categories". [Process. I removed everything (it worked), added back groups of links until it broke; removed group then added individual links, until it broke again. Refreshed whole list minus the one category, worked. Hid category watch, put the full list back in and it worked; unhide categories, full list, it breaks. ] Someone else added the same category, and was unable to replicate it, though I can add and remove category repeatedly reproduce the killer. Also to note that safemode had no effect, it wasn't a js/css issue.

It is not related to the size of the watchlist as I can get it to fail with just the one.

For me, the "Category:Speedy deletion requests" is problematic at English Wikisource, and it is one that I have watched for a while. Someone added it locally without issue, though that is a test of one, it would be worthwhile someone else having a go and looking at the server conniptions.

Can reproduce in latest releases of Chrome and Firefox

Darkdadaah added a comment.EditedApr 28 2017, 6:32 PM

I did the same and the one category that failed was "Catégorie:Suppressions immédiates demandées", which is the exact equivalent of "Category:Speedy deletion requests" on fr.wiktionary.

We can assume this is not a mere coincidence... Those categories are not "Special", so maybe their common factor is that their pages tend to be quickly deleted, and that could have conflicted with a watchlist trying to get the changes in the categories?

Dereckson updated the task description. (Show Details)
Dereckson renamed this task from Viewing my watchlist (~5000 entries) returns a blank page or an HTTP 503 error when "Hide: Page categorisation" is activated to MediaWiki\Linker\LinkRenderer::makeKnownLink() must implement interface MediaWiki\Linker\LinkTarget, null given on Special:Watchlist.

Nope, the error stacktrace excludes these functions and I think it's a older issue, as we've seen the error on fatalmonitor for some months. Now we know where it happens with a full stacktrace.

Dereckson updated the task description. (Show Details)Apr 28 2017, 8:09 PM

Mentioned in SAL (#wikimedia-operations) [2017-04-28T20:23:18Z] <Dereckson> Live debug on mwdebug1001 for T164059

Dereckson updated the task description. (Show Details)Apr 28 2017, 8:43 PM
Dereckson updated the task description. (Show Details)Apr 28 2017, 8:55 PM

Change 350914 had a related patch set uploaded (by Dereckson; owner: Dereckson):
[mediawiki/core@master] Fix EnhancedChangesList::getDiffHistLinks null exception

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

I did the same and the one category that failed was "Catégorie:Suppressions immédiates demandées", which is the exact equivalent of "Category:Speedy deletion requests" on fr.wiktionary.

We can assume this is not a mere coincidence... Those categories are not "Special", so maybe their common factor is that their pages tend to be quickly deleted, and that could have conflicted with a watchlist trying to get the changes in the categories?

Maybe it is connected with wikidata? Only way that the two are connected.

https://www.wikidata.org/w/index.php?title=Special:RecentChangesLinked&hidecategorization=0&hidepatrolled=0&target=Category%3AWikidata%3ADeletion&enhanced=1 is another test case. The cause seems to be that obsolete entries haven't been deleted from recentchanges table after member of the category has been deleted.

Maybe it is connected with wikidata? Only way that the two are connected.

Wiktionaries are not using Wikidata yet.

I had the same issues in RecentChanges. Do note that while disabling categorisation works, disabling advanced recent changes (aka grouping by page) also makes the problem go away.

Just had the same issue, in grouping mode in hewiki, categorisation disabling helps indeed.

jcrespo added a subscriber: jcrespo.

Some people seem to have complained about this on list, the workarounds at T164059#3221191 T164059#3223806 seems to work for them, so that should probably get more visibility to reach more people with similar issues.

Explicitly noting three temporary means to resolve

  • Stop watching categories, ie. turn on Hide categorization of pages in watchlist preferences
  • Turn off Expand watchlist to show all changes, not just the most recent in watchlist preferences
  • temporarily remove Category:Speedy deletion requests (or similar offending categories) via Special:EditWatchlist/raw
Nnvu added a subscriber: Nnvu.May 5 2017, 10:55 AM
Mbch331 added a subscriber: Mbch331.May 5 2017, 4:18 PM
Nirmos added a subscriber: Nirmos.May 8 2017, 6:57 PM

Are the 503 errors I have seen on RecentChanges – reported in T164448 – in any way related to this task?

@Nirmos You can try "three temporary means to resolve" above.

$pageTitle = $rc->getTitle(); in the getDiffHistLinks method can return null, a case not currently handled.

AFAICT that is incorrect. $rc->getTitle() is never null, even if given a totally invalid title. However, Title::newFromID( $rc->getAttribute( 'rc_cur_id' ) ) can certainly return null. So this is likely triggered when job queue hasn't yet deleted things from recentchanges or if the job is missed.

Change 354602 had a related patch set uploaded (by Brian Wolff; owner: Brian Wolff):
[mediawiki/core@master] Fix EnhancedChangesList::getDiffHistLinks null exception

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

Change 350914 abandoned by Dereckson:
Fix EnhancedChangesList::getDiffHistLinks null exception

Reason:
An alternative solution offers to only check pageTitle and skip the infringing lines @ https://gerrit.wikimedia.org/r/#/c/354602/

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

Change 354602 merged by jenkins-bot:
[mediawiki/core@master] Fix EnhancedChangesList::getDiffHistLinks null exception

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