Page MenuHomePhabricator

includes/Revision/RevisionStore.php: Main slot of revision (number) not found in database!
Open, MediumPublic

Description

Noticed in mediawiki-errors for both wmf.8 an wmf.9

[XBuw4QpAICMAALTXkHkAAABG] /w/index.php?title=Speci%C3%A1lis:Lap_%C3%A1tnevez%C3%A9se&action=submit   MediaWiki\Revision\RevisionAccessException from line 1643 of /srv/mediawiki/php-1.33.0-wmf.8/includes/Revision/RevisionStore.php: Main slot of revision 20798212 not found in database!
[XBuxngpAIDgAAJFITF8AAADO] /w/api.php?rvprop=userid%7Cuser%7Cids%7Ccontent%7Csize%7Ctimestamp%7Ccontentmodel%7Ccomment&revids=815943409&prop=revisions&format=json&rvslots=main&action=query   MediaWiki\Revision\RevisionAccessException from line 1643 of /srv/mediawiki/php-1.33.0-wmf.9/includes/Revision/RevisionStore.php: Main slot of revision 815943409 not found in database!

Impact

Through the API, querying information about some pages results in an internal_api_error response.

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

This is a known bug in the update script. The slots table was created in 1.31.10 (minor version). Normally there are only database changes in a major version. The update.php script should have automatically run the populateContentTables.php script during the upgrade, but it does not.

After having run the first part of the update.php script, and getting the error "Main slot of revision not found in database", you can run the populateContentTables.php manually, and immediately run the update.php a 2nd time to execute the remaining upgrade instructions (without restoring the database to the initial backup).

It wasn't 1.31.10... https://github.com/wikimedia/mediawiki/compare/1.31.9...1.31.10

Slots was there in 1.31.0-rc.0 as per rMW943c724198f1: MCR database schema

I get really confused now.

I do not understand then how I could possibly have encountered the error when migrating from 1.31.0 to 1.35.0?

In addition to that, I read now that https://www.mediawiki.org/wiki/Manual:PopulateContentTables.php was only introduced with MediaWiki 1.32.0?

Can any developer shed a light on this strange error? Or is "slot(s)" just used in two different contexts?

I get really confused now.

I do not understand then how I could possibly have encountered the error when migrating from 1.31.0 to 1.35.0?

In addition to that, I read now that https://www.mediawiki.org/wiki/Manual:PopulateContentTables.php was only introduced with MediaWiki 1.32.0?

Can any developer shed a light on this strange error? Or is "slot(s)" just used in two different contexts?

I wrote the relevant schema change. When and why the error occurs is still not clear to me.

As to the versions: if I recall correctly, we added the tables to the schema in 1.31, but using them was experimental. In 1.32, we made the installer perform the migration to the new schema.

I am not aware of a bug that would prevent an update from 1.31 to 1.35, but I have not tested this recently. There were some people who had issues because the migration script choked on data corruption in the database left over from previous bugs or buggy extensions, and were left with a partially migrated database.

This ticket is still open because we are still trying to understand the circumstances that lead to this issue.

Krinkle added subscribers: ArielGlenn, tstarling.

May I suggest we stuff the revId right into the exception message? it's passed as a parameter to the logger but doesn't end up being logged afaict, at least I don't find it in the logstash entry. See e.g. https://logstash.wikimedia.org/app/discover#/doc/logstash-*/logstash-deploy-2021.05.13?id=yqfCZXkBA6MeBtBq-eAT

Don't get me wrong but it appears that this issue is a monument of defeat. In my 15 years of MediaWiki I have never encountered MediaWiki core update errors:

el_id 112400 - 112600 of 112555
Done, 55972 rows updated.
done.
Modifying el_index_60 field of table externallinks ...done.
Running maintenance/deduplicateArchiveRevId.php...
Deduplicating ar_rev_id...
MediaWiki\Revision\RevisionAccessException from line 1296 of /../w/includes/Revision/RevisionStore.php: Main slot of revision not found in database. See T212428.
#0 /../w/includes/Revision/RevisionStore.php(1224): MediaWiki\Revision\RevisionStore->constructSlotRecords('40782', Object(Wikimedia\Rdbms\ResultWrapper), 1, Object(Title))
#1 /../w/includes/Revision/RevisionStore.php(1220): MediaWiki\Revision\RevisionStore->loadSlotRecords('40782', 1, Object(Title))
#2 /../w/includes/Revision/RevisionStore.php(1335): MediaWiki\Revision\RevisionStore->loadSlotRecords('40782', 0, Object(Title))
#3 [internal function]: MediaWiki\Revision\RevisionStore->MediaWiki\Revision\{closure}()
#4 /../w/includes/Revision/RevisionSlots.php(175): call_user_func(Object(Closure))
#5 /../w/includes/Revision/RevisionSlots.php(117): MediaWiki\Revision\RevisionSlots->getSlots()
#6 /../w/includes/Revision/RevisionRecord.php(192): MediaWiki\Revision\RevisionSlots->getSlot('main')
#7 /../w/includes/Revision/RevisionRecord.php(175): MediaWiki\Revision\RevisionRecord->getSlot('main', 1, NULL)
#8 /../w/includes/cache/MessageCache.php(1202): MediaWiki\Revision\RevisionRecord->getContent('main')
#9 /../w/includes/libs/objectcache/wancache/WANObjectCache.php(1529): MessageCache->{closure}(false, 86400, Array, NULL, Array)
#10 /../w/includes/libs/objectcache/wancache/WANObjectCache.php(1376): WANObjectCache->fetchOrRegenerate('DB9009620181219...', 86400, Object(Closure), Array, Array)
#11 /../w/includes/cache/MessageCache.php(1222): WANObjectCache->getWithSetCallback('DB9009620181219...', 86400, Object(Closure))
#12 /../w/includes/libs/objectcache/BagOStuff.php(149): MessageCache->{closure}(3600)
#13 /../w/includes/cache/MessageCache.php(1224): BagOStuff->getWithSetCallback('DB9009620181219...', 3600, Object(Closure))
#14 /../w/includes/cache/MessageCache.php(1126): MessageCache->loadCachedMessagePageEntry('Mainpage', 'de', '6c01cc743aa6c8c...')
#15 /../w/includes/cache/MessageCache.php(1034): MessageCache->getMsgFromNamespace('Mainpage', 'de')
#16 /../w/includes/cache/MessageCache.php(1005): MessageCache->getMessageForLang(Object(Language), 'mainpage', true, Array)
#17 /../w/includes/cache/MessageCache.php(947): MessageCache->getMessageFromFallbackChain(Object(Language), 'mainpage', true)
#18 /../w/includes/language/Message.php(1304): MessageCache->get('mainpage', true, Object(Language))
#19 /../w/includes/language/Message.php(862): Message->fetchMessage()
#20 /../w/includes/language/Message.php(954): Message->toString('text')
#21 /../w/includes/Title.php(661): Message->text()
#22 /../w/maintenance/populateArchiveRevId.php(213): Title::newMainPage()
#23 /../w/maintenance/populateArchiveRevId.php(118): PopulateArchiveRevId::makeDummyRevisionRow(Object(Wikimedia\Rdbms\MaintainableDBConnRef))
#24 /../w/maintenance/deduplicateArchiveRevId.php(46): PopulateArchiveRevId::checkMysqlAutoIncrementBug(Object(Wikimedia\Rdbms\MaintainableDBConnRef))
#25 /../w/maintenance/includes/LoggedUpdateMaintenance.php(45): DeduplicateArchiveRevId->doDBUpdates()
#26 /../w/includes/installer/DatabaseUpdater.php(1151): LoggedUpdateMaintenance->execute()
#27 /../w/includes/installer/DatabaseUpdater.php(554): DatabaseUpdater->runMaintenance('DeduplicateArch...', 'maintenance/ded...')
#28 /../w/includes/installer/DatabaseUpdater.php(517): DatabaseUpdater->runUpdates(Array, false)
#29 /../w/maintenance/update.php(181): DatabaseUpdater->doUpdates(Array)
#30 /../w/maintenance/doMaintenance.php(107): UpdateMediaWiki->execute()
#31 /../w/maintenance/update.php(253): require_once('/var/www/html/w...')
#32 {main}

All update tasks prior to this one went through allrighty. I did not even get into the expected cleanupUsersWithNoId pain. Anyhow, running "populateContentTables.php" as suggested by @Geertivp (T212428#6669851) followed by another start of "update.php" helped me get out of the situation. Keeping fingers crossed.

using version 1.36.1 about one out of every 5 pages has this error:

Original exception: [ca9fa5de59bd1b240f0af9a6] /mediawiki/index.php/pro4/Global_Function_notes MediaWiki\Revision\RevisionAccessException: Main slot of revision not found in database. See T212428.
Backtrace:
from /var/www/mediawiki-1.36.1/includes/Revision/RevisionStore.php(1479)
#0 /var/www/mediawiki-1.36.1/includes/Revision/RevisionStore.php(1409): MediaWiki\Revision\RevisionStore->constructSlotRecords()
#1 /var/www/mediawiki-1.36.1/includes/Revision/RevisionStore.php(1405): MediaWiki\Revision\RevisionStore->loadSlotRecords()
#2 /var/www/mediawiki-1.36.1/includes/Revision/RevisionStore.php(1518): MediaWiki\Revision\RevisionStore->loadSlotRecords()
#3 [internal function]: MediaWiki\Revision\RevisionStore->MediaWiki\Revision\{closure}()
#4 /var/www/mediawiki-1.36.1/includes/Revision/RevisionSlots.php(167): call_user_func()
#5 /var/www/mediawiki-1.36.1/includes/Revision/RevisionSlots.php(109): MediaWiki\Revision\RevisionSlots->getSlots()
#6 /var/www/mediawiki-1.36.1/includes/Revision/RevisionRecord.php(181): MediaWiki\Revision\RevisionSlots->getSlot()
#7 /var/www/mediawiki-1.36.1/includes/page/WikiPage.php(741): MediaWiki\Revision\RevisionRecord->getSlot()
#8 /var/www/mediawiki-1.36.1/includes/libs/objectcache/wancache/WANObjectCache.php(1707): WikiPage->{closure}()
#9 /var/www/mediawiki-1.36.1/includes/libs/objectcache/wancache/WANObjectCache.php(1539): WANObjectCache->fetchOrRegenerate()
#10 /var/www/mediawiki-1.36.1/includes/page/WikiPage.php(755): WANObjectCache->getWithSetCallback()
#11 /var/www/mediawiki-1.36.1/includes/page/WikiPage.php(328): WikiPage->getContentModel()
#12 /var/www/mediawiki-1.36.1/includes/page/WikiPage.php(314): WikiPage->getContentHandler()
#13 /var/www/mediawiki-1.36.1/includes/page/Article.php(2400): WikiPage->getActionOverrides()
#14 /var/www/mediawiki-1.36.1/includes/actions/Action.php(119): Article->getActionOverrides()
#15 /var/www/mediawiki-1.36.1/includes/actions/Action.php(178): Action::factory()
#16 /var/www/mediawiki-1.36.1/includes/MediaWiki.php(171): Action::getActionName()
#17 /var/www/mediawiki-1.36.1/includes/MediaWiki.php(875): MediaWiki->getAction()
#18 /var/www/mediawiki-1.36.1/includes/MediaWiki.php(546): MediaWiki->main()
#19 /var/www/mediawiki-1.36.1/index.php(53): MediaWiki->run()
#20 /var/www/mediawiki-1.36.1/index.php(46): wfIndexMain()
#21 {main}

Exception caught inside exception handler: [ca9fa5de59bd1b240f0af9a6] /mediawiki/index.php/pro4/Global_Function_notes MediaWiki\Revision\RevisionAccessException: Main slot of revision not found in database. See T212428.
Backtrace:
from /var/www/mediawiki-1.36.1/includes/Revision/RevisionStore.php(1479)
#0 /var/www/mediawiki-1.36.1/includes/Revision/RevisionStore.php(1409): MediaWiki\Revision\RevisionStore->constructSlotRecords()
#1 /var/www/mediawiki-1.36.1/includes/Revision/RevisionStore.php(1405): MediaWiki\Revision\RevisionStore->loadSlotRecords()
#2 /var/www/mediawiki-1.36.1/includes/Revision/RevisionStore.php(1518): MediaWiki\Revision\RevisionStore->loadSlotRecords()
#3 [internal function]: MediaWiki\Revision\RevisionStore->MediaWiki\Revision\{closure}()
#4 /var/www/mediawiki-1.36.1/includes/Revision/RevisionSlots.php(167): call_user_func()
#5 /var/www/mediawiki-1.36.1/includes/Revision/RevisionSlots.php(109): MediaWiki\Revision\RevisionSlots->getSlots()
#6 /var/www/mediawiki-1.36.1/includes/Revision/RevisionRecord.php(181): MediaWiki\Revision\RevisionSlots->getSlot()
#7 /var/www/mediawiki-1.36.1/includes/page/WikiPage.php(741): MediaWiki\Revision\RevisionRecord->getSlot()
#8 /var/www/mediawiki-1.36.1/includes/libs/objectcache/wancache/WANObjectCache.php(1707): WikiPage->{closure}()
#9 /var/www/mediawiki-1.36.1/includes/libs/objectcache/wancache/WANObjectCache.php(1539): WANObjectCache->fetchOrRegenerate()
#10 /var/www/mediawiki-1.36.1/includes/page/WikiPage.php(755): WANObjectCache->getWithSetCallback()
#11 /var/www/mediawiki-1.36.1/includes/page/WikiPage.php(328): WikiPage->getContentModel()
#12 /var/www/mediawiki-1.36.1/includes/page/WikiPage.php(314): WikiPage->getContentHandler()
#13 /var/www/mediawiki-1.36.1/includes/page/Article.php(2400): WikiPage->getActionOverrides()
#14 /var/www/mediawiki-1.36.1/includes/actions/Action.php(119): Article->getActionOverrides()
#15 /var/www/mediawiki-1.36.1/includes/actions/Action.php(178): Action::factory()
#16 /var/www/mediawiki-1.36.1/includes/skins/SkinTemplate.php(176): Action::getActionName()
#17 /var/www/mediawiki-1.36.1/includes/skins/SkinMustache.php(185): SkinTemplate->wrapHTML()
#18 /var/www/mediawiki-1.36.1/skins/Vector/includes/SkinVector.php(177): SkinMustache->getTemplateData()
#19 /var/www/mediawiki-1.36.1/includes/skins/SkinMustache.php(136): SkinVector->getTemplateData()
#20 /var/www/mediawiki-1.36.1/includes/skins/SkinTemplate.php(146): SkinMustache->generateHTML()
#21 /var/www/mediawiki-1.36.1/includes/OutputPage.php(2634): SkinTemplate->outputPage()
#22 /var/www/mediawiki-1.36.1/includes/exception/MWExceptionRenderer.php(147): OutputPage->output()
#23 /var/www/mediawiki-1.36.1/includes/exception/MWExceptionRenderer.php(66): MWExceptionRenderer::reportHTML()
#24 /var/www/mediawiki-1.36.1/includes/exception/MWExceptionHandler.php(106): MWExceptionRenderer::output()
#25 /var/www/mediawiki-1.36.1/includes/exception/MWExceptionHandler.php(185): MWExceptionHandler::report()
#26 /var/www/mediawiki-1.36.1/includes/MediaWiki.php(565): MWExceptionHandler::handleException()
#27 /var/www/mediawiki-1.36.1/index.php(53): MediaWiki->run()
#28 /var/www/mediawiki-1.36.1/index.php(46): wfIndexMain()
#29 {main}

6 weeks aro, I tried to upgrade from 1.31 to 1.36 and got exceptions on every page. so I went version by version that I could download to 1.34.

from 1.31 to 1.32.0-rc.1 we had this error:

MediaWiki internal error.
Original exception: [ccea2904231d5425df5b872d] /mediawiki/index.php
MediaWiki\Revision\RevisionAccessException from line 1635 of
/var/www/mediawiki-1.32.0-rc.1/includes/Revision/RevisionStore.php: Main slot of revision 32160 not found in
database!

setting this in LocalSettings.php fixed:

$wgMultiContentRevisionSchemaMigrationStage = SCHEMA_COMPAT_OLD

1.32.6 also needed SCHEMA_COMPAT_OLD

1.34.4 neeed

$wgMultiContentRevisionSchemaMigrationStage =  SCHEMA_COMPAT_WRITE_BOTH | SCHEMA_COMPAT_READ_OLD

afair at php maintenance/update.php --quick --force for 1.36.1 $wgMultiContentRevisionSchemaMigrationStage had to be removed per a warning from LocalSettings.php

anyway wiki pages will not start with that setting .

I did try the following, and the wiki pages that had the error still have the error:

:# php maintenance/populateContentTables.php
Populating revision...
No need to populate, revision.rev_text_id field does not exist
Populating archive...
No need to populate, archive.ar_text_id field does not exist
Done. Processed 0 rows in 0.013006925582886 seconds

I was in 1.22 version, and I am running updates version by version. Until version 1.32 everything alrigth, but 1.32 to 1.33 happen the error below:

Failed to populate content table revision row batch starting at 2001 due to exception: Wikimedia\Assert\ParameterTypeException: Bad value for parameter $blob: must be a string in /var/www/wiki/vendor/wikimedia/assert/src/Assert.php:105

But as the site still, works, I followed updating: 1.34 running update with the same error message, but ok; now I stuck in 1.35 version with this message on site:

Original exception: [90d3a69fab9bb1181891687f] /Lyceum MediaWiki\Revision\RevisionAccessException from line 1296 of /var/www/wiki/includes/Revision/RevisionStore.php: Main slot of revision not found in database. See T212428.
Backtrace:
#0 /var/www/wiki/includes/Revision/RevisionStore.php(1224): MediaWiki\Revision\RevisionStore->constructSlotRecords(string, Wikimedia\Rdbms\ResultWrapper, integer, Title)
#1 /var/www/wiki/includes/Revision/RevisionStore.php(1220): MediaWiki\Revision\RevisionStore->loadSlotRecords(string, integer, Title)
#2 /var/www/wiki/includes/Revision/RevisionStore.php(1335): MediaWiki\Revision\RevisionStore->loadSlotRecords(string, integer, Title)
#3 [internal function]: MediaWiki\Revision\RevisionStore->MediaWiki\Revision\{closure}()
#4 /var/www/wiki/includes/Revision/RevisionSlots.php(175): call_user_func(Closure)
#5 /var/www/wiki/includes/Revision/RevisionSlots.php(117): MediaWiki\Revision\RevisionSlots->getSlots()
#6 /var/www/wiki/includes/Revision/RevisionRecord.php(192): MediaWiki\Revision\RevisionSlots->getSlot(string)
#7 /var/www/wiki/includes/page/WikiPage.php(643): MediaWiki\Revision\RevisionRecord->getSlot(string, integer)
#8 /var/www/wiki/includes/libs/objectcache/wancache/WANObjectCache.php(1529): WikiPage->{closure}(boolean, integer, array, NULL, array)
#9 /var/www/wiki/includes/libs/objectcache/wancache/WANObjectCache.php(1376): WANObjectCache->fetchOrRegenerate(string, integer, Closure, array, array)
#10 /var/www/wiki/includes/page/WikiPage.php(651): WANObjectCache->getWithSetCallback(string, integer, Closure)
#11 /var/www/wiki/includes/page/WikiPage.php(311): WikiPage->getContentModel()
#12 /var/www/wiki/includes/page/WikiPage.php(297): WikiPage->getContentHandler()
#13 /var/www/wiki/includes/page/Article.php(2550): WikiPage->getActionOverrides()
#14 /var/www/wiki/includes/actions/Action.php(130): Article->getActionOverrides()
#15 /var/www/wiki/includes/actions/Action.php(189): Action::factory(string, Article, RequestContext)
#16 /var/www/wiki/includes/MediaWiki.php(166): Action::getActionName(RequestContext)
#17 /var/www/wiki/includes/MediaWiki.php(903): MediaWiki->getAction()
#18 /var/www/wiki/includes/MediaWiki.php(543): MediaWiki->main()
#19 /var/www/wiki/index.php(53): MediaWiki->run()
#20 /var/www/wiki/index.php(46): wfIndexMain()
#21 {main}

I followed the topic, but I don't know how proceed now... Another mediawiki site that I updated recently from version 1.15 until 1.36 is everything run right, without warnings.

Mauricioadriano: see top of this thread:

IF YOU GET THIS ERROR WHILE UPDATING A WIKI AND YOU HAVE A DATABASE BACKUP FROM BEFORE THE UPGRADE, PLEASE SEND THE BACKUP TO @daniel.

@Mauricioadriano I proposed a workaround on 4 dec 2020, and at least 4 others confirmed that this solved their instance problem.

After getting the error message, run the populateContentTables.php script once manually. Then run the update.php a 2nd time to execute the rest of the upgrade (without requiring to restore the database to the initial backup).

There is some software problem in the sequence of releases between 1.31.10 / 1.32 and 1.35. The update.php script should have automatically run the populateContentTables.php script during the upgrade, but it does not.

@Mauricioadriano I proposed a workaround on 4 dec 2020, and at least 4 others confirmed that this solved their instance problem.

After getting the error message, run the populateContentTables.php script once manually. Then run the update.php a 2nd time to execute the rest of the upgrade (without requiring to restore the database to the initial backup).

There is some software problem in the sequence of releases between 1.31.10 / 1.32 and 1.35. The update.php script should have automatically run the populateContentTables.php script during the upgrade, but it does not.

Hi Geertvip. The first problem happens when run populateContentTables.php ("Failed to populate content table revision row batch starting at 2001 due to exception"). So, this block the further actions for this solution.

Mauricioadriano: see top of this thread:

IF YOU GET THIS ERROR WHILE UPDATING A WIKI AND YOU HAVE A DATABASE BACKUP FROM BEFORE THE UPGRADE, PLEASE SEND THE BACKUP TO @daniel.

Ok, thanks. I sended to dkinzler@wikimedia.org (is that right?).

Ok, thanks. I sended to dkinzler@wikimedia.org (is that right?).

Yes that is the email address that I sent our backup to. He replied and said these backups are useful, however not sure when they'll circle back to this. this bug is on hs list along with i 'd imagine many others. So I am confident there will eventually be a solution.

Change 731246 had a related patch set uploaded (by Cicalese; author: Cicalese):

[mediawiki/core@master] Allow populateContentTables to continue when there are bad blobs

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

I have this issue on a whole bunch of wikis that I updated from 1.31 to 1.35 (although some upgrades worked fine). Are more examples needed?

I have this issue on a whole bunch of wikis that I updated from 1.31 to 1.35 (although some upgrades worked fine). Are more examples needed?

Would you be willing and able to test the patch that I created to see if it fixes the problem for you? You could cherry-pick that patch and the one that it depends upon in the order below to whichever MediaWiki version you are using to upgrade:

I'd be interested to know:

  • Which MediaWiki version did you apply the patches to?
  • Did you experience any problems applying the patches?
  • Did patching MediaWiki fix the problem for you?

For the specific problem that @Mauricioadriano reported, the patch appears to allow the update to complete successfully. I would be very interested to know if this also helps others. If it does not, we would definitely benefit from your additional examples.

Hello CCicalese ,

I am willing to the patch. the test wiki is 1.36 .

However could someone tell me how to apply the patch?

That would be great! If you click on each of the patch links above, you can click on the 3 dot menu at the top right and select Download patch.

image.png (840×1 px, 155 KB)

Then, select Anonymous HTTP and select your favorite mechanism for downloading and applying the patch from the MediaWiki install directory.

image.png (1×2 px, 207 KB)

Probably the easiest would be to download the .diff.zip file, unzip it, and use patch to apply it.

Hello CCicalese ,
thanks for the info on getting the patch.

the wiki with issue was installed by using tar and mediawiki-1.36.1.tar.gz , not git.

is there a way to test the patch on a non git install system?

Yes, download the patch file from the bottom of the dialog and then apply it using the patch command.

@Hogom said in the task description:

Dear Daniel, how can I send the backups of my databases to you (3 DBs, Wiki-Family). The update-Skript did not mention any special number of slot, only "main slot revision not found in database", happens when upgrading from 1.31 to 1.35, but not when upgrading via 1.32 to 1.33.

@Hogom, could you please test with the two patches listed above at T212428#7446002 to see if they fix the issue for you? Please answer the questions listed there. If they do not fix the problem, then you would need to email your database backups (or a link to a location from which they can be downloaded) to dkinzler@wikimedia.org.

Dear CCicalese_WMF,

trying to apply patches at mediawiki 1.33.0 gives me 11 Hunks (from 12 actions):

patch -p1 --dry-run -i 53912d6.diff
checking file maintenance/populateContentTables.php
Hunk #1 FAILED at 21.
Hunk #2 FAILED at 73.
Hunk #3 FAILED at 273.
Hunk #4 FAILED at 359.
Hunk #5 FAILED at 368.
Hunk #6 FAILED at 381.
6 out of 6 hunks FAILED

patch -p1 --dry-run -i d80f7ad.diff
checking file includes/Storage/SqlBlobStore.php
Hunk #1 FAILED at 421.
1 out of 1 hunk FAILED
checking file maintenance/populateContentTables.php
Hunk #1 FAILED at 275.
Hunk #2 succeeded at 290 (offset -11 lines).
Hunk #3 FAILED at 367.
Hunk #4 FAILED at 378.
Hunk #5 FAILED at 396.
4 out of 5 hunks FAILED

Should I start from 1.31?

Change 735090 had a related patch set uploaded (by Cicalese; author: Cicalese):

[mediawiki/core@REL1_35] DNM: Allow populateContentTables to continue when there are bad blobs

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

Change 734920 had a related patch set uploaded (by Cicalese; author: Cicalese):

[mediawiki/core@REL1_34] DNM: Allow populateContentTables to continue when there are bad blobs

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

Change 734921 had a related patch set uploaded (by Cicalese; author: Cicalese):

[mediawiki/core@REL1_33] DNM: Allow populateContentTables to continue when there are bad blobs

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

Change 734925 had a related patch set uploaded (by Cicalese; author: Cicalese):

[mediawiki/core@REL1_32] DNM: Allow populateContentTables to continue when there are bad blobs

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

@Hogom, sorry the patch didn't apply cleanly to MW 1.33. I created the different versions of the patch above that could be tested with the respective MediaWiki version.

Dear Cindy, I'm very sorry, didn't work:

patch -p1 --dry-run -i 499196a.diff
checking file includes/Storage/SqlBlobStore.php
checking file maintenance/populateContentTables.php
Hunk #1 FAILED at 21.
Hunk #2 FAILED at 73.
Hunk #3 succeeded at 290 (offset -16 lines).
Hunk #4 FAILED at 372.
Hunk #5 FAILED at 385.
4 out of 5 hunks FAILED

In my populateContentTables.php lines 22 to 28 looks like

use MediaWiki\MediaWikiServices;
use MediaWiki\Revision\SlotRecord;
use MediaWiki\Storage\NameTableStore;
use MediaWiki\Storage\SqlBlobStore;
use Wikimedia\Assert\Assert;
use Wikimedia\Rdbms\IDatabase;
use Wikimedia\Rdbms\ResultWrapper;

And lines 67 to 72 looks like

private function initServices() {

		$this->dbw = $this->getDB( DB_MASTER );
		$this->contentModelStore = MediaWikiServices::getInstance()->getContentModelStore();
		$this->mainRoleId = MediaWikiServices::getInstance()->getSlotRoleStore()
			->acquireId( SlotRecord::MAIN );

}

I checked the other patches as well with dry-run option (REL1_34, REL1_35) but no success.

Best regards

@Hogom, thank you for trying to apply the patch. It looks like you are not running the latest version of MW 1.33, so it is missing at least one other patch (https://gerrit.wikimedia.org/r/c/mediawiki/core/+/542232). It may not be fruitful to continue trying to patch that version.

You mentioned that the problem you had was upgrading from MW 1.31 to MW 1.35, not MW 1.33. Have you tried applying the MW 1.35 version of the patch to your MW 1.35 installation to see if it fixes that problem?

Dear Cindy Cicalese,

thanks a lot for your answer. You are right, it’s 1.33.0. I will try again to patch my last 1.31-Version. I think, this is what you mean.

Best regards

Von: CCicalese_WMF <no-reply@phabricator.wikimedia.org>
Gesendet: Donnerstag, 28. Oktober 2021 17:25
An: Phabricator <no-reply@phabricator.wikimedia.org>
Cc: holgerd@tops.net
Betreff: [Maniphest] [Commented On] T212428: includes/Revision/RevisionStore.php: Main slot of revision (number) not found in database!

CCicalese_WMF added a comment.
View Task

@Hogom, thank you for trying to apply the patch. It looks like you are not running the latest version of MW 1.33, so it is missing at least one other patch (https://gerrit.wikimedia.org/r/c/mediawiki/core/+/542232). It may not be fruitful to continue trying to patch that version.
You mentioned that the problem you had was upgrading from MW 1.31 to MW 1.35, not MW 1.33. Have you tried applying the MW 1.35 version of the patch to your MW 1.35 installation to see if it fixes that problem?

TASK DETAIL
https://phabricator.wikimedia.org/T212428

EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: daniel, CCicalese_WMF
Cc: Hogom, yakatz, Mauricioadriano, RobFantini, Grandeescanciano, tstarling, ArielGlenn, Nikerabbit, Kghbln, ahmad, Sam-m888, Chriscant, Oznogon, Leeshore1966, Geertivp, vitlav, Subfader, JFolvarcik, Reedy, JJMC89, BPirkle, Xover, RolandUnger, MF-Warburg, brennen, thcipriani, Headingtona, WDoranWMF, CCicalese_WMF, gerritbot, Cosine02, Marostegui, daniel, Aklapper, Suran38, Biggs657, Lalamarie69, Juan90264, Naike, Alter-paule, Beast1978, ItamarWMDE, Un1tY, eprodromou, Hook696, darthmon_wmde, Kent7301, joker88john, DannyS712, CucyNoiD, Gaboe420, Giuliamocci, Cpaulf30, Af420, Bsandipan, Lewizho99, Maathavan, Agabi10, Pchelolo, Verdy_p, Jdforrester-WMF, Jay8g, Ltrlg

@Hogom, you will need to patch the version of MediaWiki that you are trying to update *to* (in this case, MediaWiki 1.35), not the version you are trying to update *from*. You will then run maintenance/update.php, which will run maintenance/populateContentTables.php.

I should note that, if maintenance\populateContentTables.php ran previously and did not complete successfully, it is possible that it will not run again when maintenance\update.php runs, in which case you will need to run maintenance\populateContentTables.php manually after running maintenance\update.php on the target MediaWiki version.

Allright, I’m sorry, it is my first mediawiki project. I will apply the 34a8df1.diff. Or if that will not work, I’ll try d80f7ad.diff and 53912d6.diff

Von: CCicalese_WMF <no-reply@phabricator.wikimedia.org>
Gesendet: Donnerstag, 28. Oktober 2021 18:16
An: Phabricator <no-reply@phabricator.wikimedia.org>
Cc: holgerd@tops.net
Betreff: [Maniphest] [Commented On] T212428: includes/Revision/RevisionStore.php: Main slot of revision (number) not found in database!

CCicalese_WMF added a comment.
View Task

@Hogom, you will need to patch the version of MediaWiki that you are trying to update *to* (in this case, MediaWiki 1.35), not the version you are trying to update *from*. You will then run maintenance/update.php, which will run maintenance/populateContentTables.php.

TASK DETAIL
https://phabricator.wikimedia.org/T212428

EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: daniel, CCicalese_WMF
Cc: Hogom, yakatz, Mauricioadriano, RobFantini, Grandeescanciano, tstarling, ArielGlenn, Nikerabbit, Kghbln, ahmad, Sam-m888, Chriscant, Oznogon, Leeshore1966, Geertivp, vitlav, Subfader, JFolvarcik, Reedy, JJMC89, BPirkle, Xover, RolandUnger, MF-Warburg, brennen, thcipriani, Headingtona, WDoranWMF, CCicalese_WMF, gerritbot, Cosine02, Marostegui, daniel, Aklapper, Suran38, Biggs657, Lalamarie69, Juan90264, Naike, Alter-paule, Beast1978, ItamarWMDE, Un1tY, eprodromou, Hook696, darthmon_wmde, Kent7301, joker88john, DannyS712, CucyNoiD, Gaboe420, Giuliamocci, Cpaulf30, Af420, Bsandipan, Lewizho99, Maathavan, Agabi10, Pchelolo, Verdy_p, Jdforrester-WMF, Jay8g, Ltrlg

Lots of Thanks. The update script ran without any errors. First copied the mediawiki 1.35.4 source files to document root, then applied patch 34a8df1.diff, finally ran update.php with doshared option.

@Hogom that's great news! Thank you so much for testing the patch in your environment!

Change 731246 merged by jenkins-bot:

[mediawiki/core@master] Allow populateContentTables to continue when there are bad blobs

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

Change 736516 had a related patch set uploaded (by Cicalese; author: Cicalese):

[mediawiki/core@REL1_37] Allow populateContentTables to continue when there are bad blobs

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

Change 736517 had a related patch set uploaded (by Cicalese; author: Cicalese):

[mediawiki/core@REL1_36] Allow populateContentTables to continue when there are bad blobs

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

Change 734925 abandoned by Cicalese:

[mediawiki/core@REL1_32] Allow populateContentTables to continue when there are bad blobs

Reason:

don't need to support upgrade to obsolete version

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

Change 734921 abandoned by Cicalese:

[mediawiki/core@REL1_33] Allow populateContentTables to continue when there are bad blobs

Reason:

don't need to support upgrade to obsolete version

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

Change 734920 abandoned by Cicalese:

[mediawiki/core@REL1_34] Allow populateContentTables to continue when there are bad blobs

Reason:

don't need to support upgrade to obsolete version

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

Hello
we have wiki version 1.36.2

since i installed using a tarball i tried using a tar Archive to fix the wiki. I did the following:

tar xf /root/b62c850.tar.xz
composer update --no-dev
php maintenance/update.php
chown www-data cache

the T212428 was not solved. .

Was it OK to try an archive ?

I also tried:

php maintenance/populateContentTables.php
Populating revision...
No need to populate, revision.rev_text_id field does not exist
Populating archive...
No need to populate, archive.ar_text_id field does not exist
Done. Processed 0 rows in 0.011786937713623 seconds

I can easily restore a system snapshot and try again.

@RobFantini the fix has not been backported to any release version of MediaWiki yet. After the backport has landed, you will still have to wait for a bugfix release of the respective version of MediaWiki. Until then, you can try to manually apply Cindy's patch to your installation.

Also note: "No need to populate, revision.rev_text_id field does not exist" indicates that you already updated to a version of MediaWiki that dropped the rev_text_id field. It is not possible to restart the migration process from there. You will have to restore the database to a state from before the update to your current version.

I set up a new git based version 1.36 system using this command

git clone https://gerrit.wikimedia.org/r/mediawiki/core.git --branch REL1_36 mediawiki

then restored database from 1.34

I have a question on which patch file to download..

using cherry pick 1.36 link : https://gerrit.wikimedia.org/r/c/mediawiki/core/+/736517

after clicking Download there are a few git commands listed. should I do this one?

Cherry Pick

git fetch https://gerrit.wikimedia.org/r/mediawiki/core refs/changes/17/736517/1 && git cherry-pick FETCH_HEAD
git fetch https://gerrit.wikimedia.org/r/mediawiki/core refs/changes/17/736517/1 && git cherry-pick FETCH_HEAD

Yes, that should do the right thing.

Change 735090 merged by jenkins-bot:

[mediawiki/core@REL1_35] Allow populateContentTables to continue when there are bad blobs

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

Change 736516 merged by jenkins-bot:

[mediawiki/core@REL1_37] Allow populateContentTables to continue when there are bad blobs

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

Change 736517 merged by jenkins-bot:

[mediawiki/core@REL1_36] Allow populateContentTables to continue when there are bad blobs

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

This task is no longer a blocker for MediaWiki 1.37. https://gerrit.wikimedia.org/r/c/mediawiki/core/+/731246 fixes some of the problematic behavior and has been backported to the 1.35, 1.36, and 1.37 branches. However, there is still some work to be done on this task as noted by @daniel on the patch:

[T]his patch prevents the populateContentTables script from failing on bad blobs for revisions that are missing rev_len or rev_sha1. Such revisions will get a content row with a "known bad" content address. Viewing pages with known bad content will show an empty page. However, bad blobs or text_ids are not detected if the revision has rev_sha1 and rev_len. In that case, content rows with a bad content address will be produced. Attempting to view pages with such bad content addresses will produce an error similar to the one that would have happened before conversion. ... In order to detect bad valus in rev_text_id, we'd need to do a left join on the text table. We would still not reliably detect issues with the blob itself, like corrupt compressed data or bad external store references, but these are unlikely in third party installations anyway, and can be caught later.

git fetch https://gerrit.wikimedia.org/r/mediawiki/core refs/changes/17/736517/1 && git cherry-pick FETCH_HEAD

Yes, that should do the right thing.

Success here. patch fixed our issues with version 1.36.2 .

Thank you very much for the well done work Cindy Cicalese and Daniel

That's great news! Thank you for testing the patch!

Hello ,
we found some pages that have the 'Main slot of revision not found in database. See T212428 issue.'

the issue occurs when a pdf thumbnail is clicked to enlarge ,

and if i search the term ' pdf '

we are still investigating...

also i tried uploading a new pdf file, and that displayed okay - i did not put the pdf to a wiki page and test yet.....

we are using extenstions from 1.34 , i will replace those using

git clone https://gerrit.wikimedia.org/r/mediawiki/extensions/<name>     --branch REL1_36

Hello ,
we found some pages that have the 'Main slot of revision not found in database. See T212428 issue.'

The original problem was that the update does not complete when there are pages that have bad data.
The fix makes sure that the update just skips pages with bad data, and continues.
But after the update, these pages still have bad data. If you try to load them, you still get an error. The error may be different from what you saw on the page before the update - maybe in the past, it just looked empty.

If you know roughly the time or the ID of the revision with the bad data, you may be able to use maintenance/findBadBlobs.php to mark them as "known bad". This will make the revision appear empty, and not display an error.

Hello
So we upgraded our wiki to v136 thanks to the patch. randomly we are running in to the [ we assume ] not too many pages to fix. fixing is not always easy. there is so far no consistency to which type of page will have the bug. more on that if you wish later.
to help us and others get all bug pages fixed answers to the questions below would help. besides these questions please chime in with any suggestions. I am happy the bug is fixed, and just want to get all the cleanup done in the next week or so instead someone reporting a bug page in 8 months then looking at the notes on how to do this. as i get going on this a wiki page should get made and link left here with user figured out problems and solutions that worked.

how can I find the find time or the ID of the revision with the bad data ?

is there a way from command line to list all pages that have the T212428 issue?

is there a way to delete a page or media from command line? because we can then copy and paste the page back from old wiki version. [ I see of no way to delete a page at wiki, the bug pops up . perhaps there is an extension for that?]

This comment was removed by RobFantini.

how can I find the find time or the ID of the revision with the bad data ?

From the page history of a broken page. That page should still show, and display timestamps. If the current version of the page is broken, then it will be the newest timestamp in the history.

is there a way from command line to list all pages that have the T212428 issue?

You can run findBadBlobs() to find them all. You can set a long-ago start date, and a high limit, and it will find them all. It may just take a long time if you have many revisions.

is there a way to delete a page or media from command line?

You have to repair the pages first, then they can be deleted normally.

because we can then copy and paste the page back from old wiki version. [ I see of no way to delete a page at wiki, the bug pops up . perhaps there is an extension for that?]

Are there pages that show an error after the update, but actually have content on the old wiki?
So far, we have only seen this bug when the data was already lost. The error may show in a different way, but the old wiki version wouldn't have any content.

If you are seeing any pages that have content in the old version, but show an error after upgrade (with the patch), please let us know! That would mean we have not found all problems.

Hi Daniel
re: "Are there pages that show an error after the update, but actually have content on the old wiki?
So far, we have only seen this bug when the data was already lost. The error may show in a different way, but the old wiki version wouldn't have any content.

If you are seeing any pages that have content in the old version, but show an error after upgrade (with the patch), please let us know! That would mean we have not found all problems."

Yes we have example of that .

So far most of the issues have been with media. However there was at least one text only page that I dealt with.

as you already have our database [ let me know if a resend is needed ] I can send links.

Can populateContentTables.php be run multiple times without causing harm? It seems like there is no issue, but want to be certain before telling my orchestration system to respond to errors in update.php that look similar to this by trying populateContentTables.php.

I have over 20 wikis on 1.31.12 in production that nightly get copied to a dev server and upgraded to 1.35.4. Some have this failure, some don't. If you're still trying to diagnose why this happens, let me know if I can provide any data that could help.

Can populateContentTables.php be run multiple times without causing harm? It seems like there is no issue, but want to be certain before telling my orchestration system to respond to errors in update.php that look similar to this by trying populateContentTables.php.

Yes, you can run populateContentTables.php as often as you like. However, after full migration to the new storage schema, it won't do anything (it would say "No need to populate"). In that case, you would have to revert to an older database backup first.

You can also scan for issues using the findBadBlobs.php script, but depending on the number of revisions in your wikis, this may take quite long.

I have over 20 wikis on 1.31.12 in production that nightly get copied to a dev server and upgraded to 1.35.4. Some have this failure, some don't. If you're still trying to diagnose why this happens, let me know if I can provide any data that could help.

We found and fixed some causes, but the latest reports by @RobFantini seem to indicate that we have not found all.

I've received the same error message (Main slot of revision not found in database) while editing an entity with RaiseWikibase based on Wikibase v1.35. In my case the source of the problem was that I've inserted comment_id (=SELECT max(comment_id) FROM comment + 1) into rev_comment_id in the revision-table. When I insert just 0 into rev_comment_id, everything works as expected.

Documentation of revision-table for rev_comment_id says: "If this field contains zero in each record, the comment id must be retrieved from the revision_comment_temp table. Supposedly, this table will be merged with the table revision again in the future."

This comment was removed by StasR.

Still seen. Around 800 matching events from mediawiki-errors in Logstash during the last 30 days.