Wikimedia Bugzilla is closed!

This error is triggered by a newly inserted check that asserts that the link cache actually knows about the title in question before using the link cache to determine whether a given title is a redirect.

In the past, the case that the LinkCache didn't know about the item went unnoticed, and isRedirect would just return false even though the page in question might have been a redirect.

The way Title::isRedirect() is implemented seems quite brittle to me: it relies on the LinkCache without any fallback, and there's no intrinsic mechanism to make sure the LinkCache was actually initialize for this title.

So... I believe this problem has existed for a long time, but only now has been made obvious by the explicit check.

Yes it is very explicit. We're hitting this every few minutes on translatewiki.net and getting spammed on #mediawiki-i18n. It's mostly crawlers but I'm sure we are serving exceptions to normal users too.

Well, what you were serving before was simply wrong (at least in some cases), because redirects were not handled as such. 

Anyway, all I'm saying is: it's a bug, it should be fixed, but not by ignoring the actual problem,. but by finding and fixing the cause.

I think we have enough information to find a/the cause. In the mean time I had to disable real time error reporting.

We've got somebody getting this error during parser tests as well, during:
'Edit comment with link'

I'm can reproduce it by setting $wgLanguageCode = "de" and running parserTests.php:

Running test Edit comment with link... LinkCache doesn't currently know about this title: Main_Page
Backtrace:
#0 /Library/WebServer/Documents/core/includes/Linker.php(139): Title->isRedirect()
#1 /Library/WebServer/Documents/core/includes/Linker.php(324): Linker::getLinkColour(Object(Title), 0)
#2 /Library/WebServer/Documents/core/includes/Linker.php(240): Linker::linkAttribs(Object(Title), Array, Array)
#3 /Library/WebServer/Documents/core/includes/Linker.php(1341): Linker::link(Object(Title), 'Main Page')
#4 [internal function]: Linker::formatLinksInCommentCallback(Array)
#5 /Library/WebServer/Documents/core/includes/Linker.php(1275): preg_replace_callback('/\[\[:?(.*?)(\|...', Array, 'I like the [[Ma...')
#6 /Library/WebServer/Documents/core/includes/Linker.php(1166): Linker::formatLinksInComment('I like the [[Ma...', Object(Title), false)
#7 /Library/WebServer/Documents/core/tests/parser/parserTest.inc(483): Linker::formatComment('I like the [[Ma...', Object(Title), false)
#8 /Library/WebServer/Documents/core/tests/parser/parserTest.inc(401): ParserTest->runTest('Edit comment wi...', 'I like the [[Ma...', 'I like the <a h...', 'comment', '')
#9 /Library/WebServer/Documents/core/tests/parser/parserTest.inc(383): ParserTest->runTests(Object(TestFileIterator))
#10 /Library/WebServer/Documents/core/tests/parserTests.php(90): ParserTest->runTestsFromFiles(Array)
#11 {main}

I'm provisionally reverting this in https://gerrit.wikimedia.org/r/#/c/9952/

Needs a little more baking before it's done. :)

Revert is merged and should provisionally 'fix' the error cases, but a proper fix for the original issue is still outstanding.

Looks like Title::isRedirect()'s lazy-initialization path assumes that Title::getArticleId()'s lazy-initialization path gets executed, running through the link cache.

Sometimes this isn't the case, but I'm not 100% sure why or how.

Adjacent two methods are making the same assumption, Daniel has found! Lovely. :)

Probably they should go ahead and use the link cache, but if the link cache entry isn't there, we can't necessarily assume that the property is missing. Should fall back to a direct load (or a more general load info).

I fixed some of them in Gerrit change #9853.

*** Bug 37218 has been marked as a duplicate of this bug. ***

Adding bugs reported as "1.20", "regression" and "critical" to 1.20 release milestone.

Aude submitted Gerrit change #27528 to address this issue after the ContentHandler branch merge.

My patch doesn't fix the bug.  Instead, it removes the fatal exception.  A more proper solution is needed.  

This could be to check page_is_redirect in the database in cases where the title is not in the link cache.

The use case where the exception happened for me is with the recent changes and watchlist pages, using the enhanced changes.  There is a check in Linker::getLinkColour() if a title is a redirect, and sometimes this is called in a way that the link is not in the cache.

*** Bug 41187 has been marked as a duplicate of this bug. ***

Maybe I'm missing something, but can't this be solved by just adding $linkCache->addLinkObj( $this ) before every call of $linkCache->getGoodLinkFieldObj()? Because then the title would be added to the cache. Or perhaps I'm misunderstanding the point of LinkCache.

Lately I'm getting lot of this error (every 10 minutes when my jobqueue is supposed to run). Title seems to always be a user page.

[22-Oct-2012 13:20:01] LinkCache doesn't currently know about this title: User:Duesentrieb
Backtrace:
#0 /www/translatewiki.net/w/extensions/SemanticMediaWiki/includes/SMW_ParseData.php(200): Title->getLatestRevID()
#1 /www/translatewiki.net/w/extensions/SemanticMediaWiki/includes/SMW_ParseData.php(475): SMWParseData::storeData(Object(ParserOutput), Object(Title), true)
#2 [internal function]: SMWParseData::onLinksUpdateConstructed(Object(LinksUpdate))
#3 /www/translatewiki.net/w/includes/Hooks.php(253): call_user_func_array('SMWParseData::o...', Array)
#4 /www/translatewiki.net/w/includes/GlobalFunctions.php(3811): Hooks::run('LinksUpdateCons...', Array)
#5 /www/translatewiki.net/w/includes/LinksUpdate.php(108): wfRunHooks('LinksUpdateCons...', Array)
#6 /www/translatewiki.net/w/includes/parser/ParserOutput.php(420): LinksUpdate->__construct(Object(Title), Object(ParserOutput), false)
#7 /www/translatewiki.net/w/includes/content/AbstractContent.php(237): ParserOutput->getSecondaryDataUpdates(Object(Title), false)
#8 /www/translatewiki.net/w/includes/job/RefreshLinksJob.php(82): AbstractContent->getSecondaryDataUpdates(Object(Title), NULL, false, Object(ParserOutput))
#9 /www/translatewiki.net/w/includes/job/RefreshLinksJob.php(194): RefreshLinksJob::runForTitleInternal(Object(Title), Object(Revision), 'RefreshLinksJob...')
#10 /www/translatewiki.net/w/maintenance/runJobs.php(83): RefreshLinksJob2->run()
#11 /www/translatewiki.net/w/maintenance/doMaintenance.php(116): RunJobs->execute()
#12 /www/translatewiki.net/w/maintenance/runJobs.php(116): require_once('/www/translatew...')
#13 {main}


Backtrace is always the same.

*** Bug 41258 has been marked as a duplicate of this bug. ***

Bumping priority. This apparently causes editors to be unable to view their watchlists on pl.wikipedia right now. (Two sysops confirmed it.)

Please, somebody fix it, it was reported in May :(

https://pl.wikipedia.org/wiki/Wikipedia:Kawiarenka/Kwestie_techniczne#Update_oprogramowania_Media_Wiki_do_1.21wmf2

Ic2d3f0b8 was merged and apparently stuff stopped blowing up. Not marking as fixed, as whatever caused the issue is still there.

Thanks.

Bug 35962 has most likely been caused by the implicit failure of the LinkCache (we have worked around it there).

The explicit failure also broke other functions in Semantic MediaWiki. It is better since the exception is gone (the exception killed runJobs.php, which was a bit painful), but Semantic MediaWiki will remain affected (storing wrong page metadata when refreshjobs are run) until this problem is solved.

Changing target milestone to 1.20.x. It's definitely worth an update to 1.20.0.

Discovered this bug when testing my rebased patch for bug 22881.

Of course it breaks sometimes! The code in Title.php should not rely on entries in the LinkCache - at least, it can be sometimes cleared!

This also triggers errors on some of the core unit tests on my environment:

1) WikitextContentTest::testGetSecondaryDataUpdates with data set #0 ('WikitextContentTest_testGetSecondaryDataUpdates_1', 'wikitext', 'hello \'\'world\'\'
', array(array(true, array())))
MWException: LinkCache doesn't currently know about this title: WikitextContentTest_testGetSecondaryDataUpdates_1

/www/dev.translatewiki.net/w/includes/Title.php:2990
/www/dev.translatewiki.net/w/extensions/SemanticMediaWiki/includes/SMW_ParseData.php:245
/www/dev.translatewiki.net/w/extensions/SemanticMediaWiki/includes/SMW_ParseData.php:518
/www/dev.translatewiki.net/w/includes/Hooks.php:253
/www/dev.translatewiki.net/w/includes/GlobalFunctions.php:3852
/www/dev.translatewiki.net/w/includes/LinksUpdate.php:108
/www/dev.translatewiki.net/w/includes/parser/ParserOutput.php:458
/www/dev.translatewiki.net/w/includes/content/AbstractContent.php:237
/www/dev.translatewiki.net/w/tests/phpunit/includes/content/WikitextContentTest.php:77
/www/dev.translatewiki.net/w/tests/phpunit/MediaWikiTestCase.php:116
/www/dev.translatewiki.net/w/tests/phpunit/MediaWikiPHPUnitCommand.php:59
/www/dev.translatewiki.net/w/tests/phpunit/MediaWikiPHPUnitCommand.php:45

2) WikitextContentTest::testGetSecondaryDataUpdates with data set #1 ('WikitextContentTest_testGetSecondaryDataUpdates_2', 'wikitext', 'hello [[world test 21344]]
', array(array(true, array(array(0)))))
MWException: LinkCache doesn't currently know about this title: WikitextContentTest_testGetSecondaryDataUpdates_2

/www/dev.translatewiki.net/w/includes/Title.php:2990
/www/dev.translatewiki.net/w/extensions/SemanticMediaWiki/includes/SMW_ParseData.php:245
/www/dev.translatewiki.net/w/extensions/SemanticMediaWiki/includes/SMW_ParseData.php:518
/www/dev.translatewiki.net/w/includes/Hooks.php:253
/www/dev.translatewiki.net/w/includes/GlobalFunctions.php:3852
/www/dev.translatewiki.net/w/includes/LinksUpdate.php:108
/www/dev.translatewiki.net/w/includes/parser/ParserOutput.php:458
/www/dev.translatewiki.net/w/includes/content/AbstractContent.php:237
/www/dev.translatewiki.net/w/tests/phpunit/includes/content/WikitextContentTest.php:77
/www/dev.translatewiki.net/w/tests/phpunit/MediaWikiTestCase.php:116
/www/dev.translatewiki.net/w/tests/phpunit/MediaWikiPHPUnitCommand.php:59
/www/dev.translatewiki.net/w/tests/phpunit/MediaWikiPHPUnitCommand.php:45

(In reply to comment #15)
> Maybe I'm missing something, but can't this be solved by just adding
> $linkCache->addLinkObj( $this ) before every call of
> $linkCache->getGoodLinkFieldObj()? Because then the title would be added to
> the cache. Or perhaps I'm misunderstanding the point of LinkCache.

Could somebody comment on this, please?

Bumping to highest priority after IRC discussion with Niklas and Sumana.

<Nikerabbit> that exception is popping up in various places regularly, and is very annoying... the lqt double posting (bug 43693) was just latest one

I have a fix for it here https://gerrit.wikimedia.org/r/#/c/34339/ :-)

Rebased patch mentioned in comment 26 on master, updated the commit summary and merged. Thanks, Vitaliy.

IAlex proposed some more work in Gerrit change #43445. Please review.

Not fully fixed, see bug 43899.

(In reply to comment #29)
> Not fully fixed, see bug 43899.

Gerrit change #43445 has not been merged yet; not sure though if that would fully fix this.

Proposed fix for this specific case in Gerrit change #45337.

Change merged.

Still has to be backported to 1.20 (for 1.20.4; it didn't make it to 1.20.3).

Gerrit change #43445 was reverted by Gerrit change #55389; reopening bug.

(In reply to comment #34)
> Gerrit change #43445 was reverted by Gerrit change #55389; reopening bug.

Ah, it would have been nice to know... This bug causes major disruption and now we have only 2 days to fix it on 1.19 and 1.20. :(

rc tarball creation is not a good reason for "immediate" priority. Resetting.

(In reply to comment #34)
> Gerrit change #43445 was reverted by Gerrit change #55389; reopening bug.

The revert got merged on March 22nd, which means it's included in 1.22wmf1 which is now deployed everywhere since April 10th.

So has anybody run into the issue originally reported here in the last days?

MatmaRex (comment 16), Niklas (comment 23):

Has any of you run into the issue in the last days again?

I haven't heard any reports, no.

Not observed on translatewiki.net since 14-Apr-2013 07:42:13 UTC.

(In reply to comment #39)
> Not observed on translatewiki.net since 14-Apr-2013 07:42:13 UTC.

Oops. I need to clarify that: Logs go back to the above date and this particular issue is not in it.

The point is how to fix this in 1.20.x...

Thanks. Currently no indicators that this still happens, hence decreasing prio/seve. Please bump up if this is seen again.

(In reply to comment #41)
> The point is how to fix this in 1.20.x...

Mark: Any comments (or decision on the backport request flag)?

From what I can see from my brief review, this looks like mostly something that affected only TranslateWiki.  Are there other reports aside from scowiki and TWN?

If not, I don't think this is critical enough for a new release.

Regarding Title::getLatestRevID(): getArticleID(0) will get the article ID cached in the object, it won't necessarily be from the same transaction as the page row used in LinkCache. But staleness is expected with $flags=0 so it wouldn't be harmful to just pick a winner. I don't understand why an exception needs to be thrown.

With $flags=GAID_FOR_UPDATE, maybe there is a greater need for freshness, but in that case, LinkCache::addLinkObj() is done unconditionally by getArticleID() against the master, which should make absence from LinkCache impossible.

Related URL: https://gerrit.wikimedia.org/r/67235 (Gerrit Change I0add48463341e56fe8c155b1007487278ad2705d)

(In reply to comment #46)
> Related URL: https://gerrit.wikimedia.org/r/67235 (Gerrit Change
> I0add48463341e56fe8c155b1007487278ad2705d)

Patch got merged two days ago. Closing as FIXED.

*** Bug 41360 has been marked as a duplicate of this bug. ***