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

This could have been caused by https://phabricator.wikimedia.org/rEFLRad612350b61786b00897f1dec44bdfac5c8ab349

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.

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

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?

In T164059#3220838, @Paladox wrote:

This could have been caused by https://phabricator.wikimedia.org/rEFLRad612350b61786b00897f1dec44bdfac5c8ab349

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.

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

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

In T164059#3221756, @Darkdadaah wrote:

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.

In T164059#3223261, @Billinghurst wrote:

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.

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

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