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.

In T212428#7427285, @Geertivp wrote:

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

In T212428#7426904, @RobFantini wrote:

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?

In T212428#7445903, @yakatz wrote:

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:

• https://gerrit.wikimedia.org/r/c/mediawiki/core/+/641332
• https://gerrit.wikimedia.org/r/c/mediawiki/core/+/731246

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.

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

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

In T212428#7487592, @RobFantini wrote:

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.

In T212428#7489591, @daniel wrote:

In T212428#7487592, @RobFantini wrote:

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

In T212428#7497535, @RobFantini wrote:

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?]

In T212428#7499312, @RobFantini wrote:

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.

In T212428#7505751, @Jamesmontalvo3 wrote:

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

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

1.37.x is now EOL.

Ran findBadBlobs.php for translatewiki.net some time ago. It would be useful if the script could be used to target specific pages or revisions, as it is very slow.

In T212428#8480897, @Nikerabbit wrote:

Ran findBadBlobs.php for translatewiki.net some time ago. It would be useful if the script could be used to target specific pages or revisions, as it is very slow.

It can:

--revisions: A list of revision IDs to process, separated by comma
    or colon or whitespace. Revisions belonging to deleted pages will work.
    If set to "-" IDs are read from stdin, one per line.

Hmm sorry it was a while ago and my memory was not right. What we did was:

1. Decrease batch size so that we could get the exact page id

abi@web2:~$ php /srv/mediawiki/workdir/extensions/CirrusSearch/maintenance/ForceSearchIndex.php --skipLinks 1 --indexOnSkip 1 --batch-size 1 --fromId 17035 --toId 17050
[translatewiki_net-bw_] Indexed 1 pages ending at 17035 at 14/second
[translatewiki_net-bw_] Indexed 1 pages ending at 17036 at 24/second
[translatewiki_net-bw_] Indexed 1 pages ending at 17037 at 30/second
[translatewiki_net-bw_] Indexed 1 pages ending at 17038 at 37/second
[translatewiki_net-bw_] Indexed 1 pages ending at 17039 at 43/second
MediaWiki\Revision\RevisionAccessException from line 1186 of /srv/mediawiki/workdir/includes/Revision/RevisionStore.php: Failed to load data blob from Unable to fetch blob at tt:30394. Use findBadBlobs.php to remedy.If this problem persist, use the findBadBlobs maintenance script to investigate the issue and mark bad blobs.

2. Find the current revision of the page

MariaDB [translatewiki_net]> select * from bw_page left join bw_revision on page_id = rev_page where page_id = 17040\G
*************************** 1. row ***************************
           page_id: 17040
    page_namespace: 2
        page_title: Kwekubo/monobook.js
  page_is_redirect: 0
       page_is_new: 1
       page_random: 0.554832332286
      page_touched: 20170321145334
       page_latest: 31075
          page_len: 1115
page_content_model: NULL
page_links_updated: NULL
         page_lang: NULL
            rev_id: 31075
          rev_page: 17040
    rev_comment_id: 0
         rev_actor: 44
     rev_timestamp: 20060603115231
    rev_minor_edit: 0
       rev_deleted: 0
           rev_len: NULL
     rev_parent_id: 0
          rev_sha1: 
1 row in set (0.001 sec)

3. Run the script manually with the revision

twn:~$ php /srv/mediawiki/workdir/maintenance/findBadBlobs.php --revisions 31075
Scanning 1 ids
        ! Found bad blob on revision 31075 from 20060603115231 (main slot): content_id=88137, address=<tt:30394>, error='Unable to fetch blob at tt:30394. Use findBadBlobs.php to remedy.', type='MediaWiki\Storage\BlobAccessException'. ID:        31075
        - Scanned a batch of 1 revisions
Found 1 bad revisions

So basically the difficult part was finding a revision(s) that point to tt:30394. Would be nice to be able to just pass that value to the script and let it do the magic.

In T212428#8482227, @Nikerabbit wrote:

So basically the difficult part was finding a revision(s) that point to tt:30394. Would be nice to be able to just pass that value to the script and let it do the magic.

Ugh, yes, that's annoying. I made a little patch to simply include the revision ID in the error message: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/869850

There is another exception which gives even less information: https://codesearch.wmcloud.org/search/?q=Main%20slot%20of%20revision%20not%20found%20in%20database&i=nope&files=&excludeFiles=&repos=

It also creates log entry with revision id, but that requires configuring the logger output for channel RevisionStore.

For anyone who encounters this problem and sadly doesn't have backups from before the upgrade (like myself), I was able to get around the problem by running the queries below on the database. These do the following:

• Updates the page_latest field on each page to the latest revision that has a corresponding slot record.
• Deletes any pages that still do not have a revision with a valid slot.

This is far from perfect, because data can be lost, but it will at least allow you to view/edit/delete pages on your wiki without getting the "Main slot of revision not found in database. See T212428." error. It is much better to restore a backup and upgrade as describe in the comments above (if possible).

PLEASE NOTE: You may lose some pages and/or find that your pages have reverted to older revisions.

update page set page_latest = (select max(rev_id) from revision where revision.rev_page = page.page_id and exists (select * from slots where slots.slot_revision_id = revision.rev_id)) where page_latest in (select rev_id from revision where not exists (select * from slots where slots.slot_revision_id = revision.rev_id)) and (select max(rev_id) from revision where revision.rev_page = page.page_id and exists (select * from slots where slots.slot_revision_id = revision.rev_id)) is not null;

delete from page where page_latest in (select rev_id from revision where not exists (select * from slots where slots.slot_revision_id = revision.rev_id));

I encountered this error after importing an xml file to my wiki, when trying to access the imported pages. Granted, it wasn't an exported xml file, I had generated it to quickly populate a number of pages. Sample XML was
<mediawiki xmlns="http://www.mediawiki.org/xml/export-0.11/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.mediawiki.org/xml/export-0.11/ http://www.mediawiki.org/xml/export-0.11.xsd" version="0.11" xml:lang="en">
<page><title>cds_links_parameter</title><revision><text>{{Accuro table|table_name=cds_links_parameter}} [[Category:Accuro table from import]] <!-- remove once edited --></text></revision></page>
<page><title>message_notes</title><revision><text>{{Accuro table|table_name=message_notes}} [[Category:Accuro table from import]] <!-- remove once edited --></text></revision></page>
...
<mediawiki>
Pages didn't show up in recent changes and when I try to go to one of the imported pages via search I get this error.
Interestingly, I did not get the error when importing a smaller number of pages with the same xml.
Another possibly related thing... I tried to "help the import along" by running the runJobs.php manually a few times...

Thanks to @Geoff.denning, I ran a modified version of his queries to remove the imported pages.

Clearly I was doing something questionable by importing like this but it has worked in the past. Just posting this in case it can contribute to a solution.