Page MenuHomePhabricator

Upgrade script from MW 1.29 to 1.32 seems to break revision table
Open, Needs TriagePublicBUG REPORT

Description

Recently installed MW 1.32 in parallel with 1.29. (Site has less than 50 pages and around 300 revisions total.) Ran the update script. 1.29 instance still works fine, but on 1.32 around 20% of pages crash with an error related to missing revision ids in the database.

Steps to Reproduce:

  • Install MW 1.29.
  • Make a half dozen edits to several pages.
  • Backup the database.
  • Install MW 1.32 in parallel.
  • Run update.php.
  • Navigate to edited pages. Several of them should fail to load, with an error related to their revision ids not being found in the database.

Actual Results:
Approximately 20% of pages give the following error (with $wgShowExceptionDetails enabled):

Original exception: [long hash] /wiki/index.php/Main_Page MediaWiki\Revision\RevisionAccessException from line 1635 of /var/www/html/wiki/includes/Revision/RevisionStore.php: Main slot of revision 296 not found in database!

Expected Results:
Pages should load properly.

Temporary Fix:
Add to LocalSettings.php either:

  • $wgMultiContentRevisionSchemaMigrationStage = SCHEMA_COMPAT_OLD;, or
  • $wgMultiContentRevisionSchemaMigrationStage = SCHEMA_COMPAT_WRITE_BOTH | SCHEMA_COMPAT_READ_OLD;

Both will work.

Happy to provide database sql file for reproduction.

Event Timeline

I have a few questions:

  • does the error always occur on the same pages, or does it happen "sometimes"?
  • does the error happen on revisions created before the update, or revisions created after the update, or both?
  • does the updatelog table contain an entry that related to PopulateContentTables or populateContentTables.php?
  • does running maintenance/populateContentTables.php fix the issue? Please make a DB dump before you try this, so we have a chance to see what the problem was.
Aklapper changed the task status from Open to Stalled.Apr 5 2019, 12:13 PM

[Blocked means stalled task status](https://www.mediawiki.org/wiki/Bug_management/Bug_report_life_cycle) hence setting that.

In my case I had several complications which may have triggered the issue. A little wiki farm with shared tables and only the option to use the webupdater. Luckily the hosting was changed in the meantime.

does the error always occur on the same pages, or does it happen "sometimes"?

sometimes, i.e. the pages with borked database data as indicated in the report

does the error happen on revisions created before the update, or revisions created after the update, or both?

only before

does the updatelog table contain an entry that related to PopulateContentTables or populateContentTables.php?

Yes, it does, however unsure if added by update.php or populateContentTables.php

does running maintenance/populateContentTables.php fix the issue?

Yes, it does, which is good.

Aklapper changed the task status from Stalled to Open.Nov 5 2020, 11:55 AM

Questions have been answered hence resetting task status.

Aklapper added a subscriber: daniel.

Removing task assignee due to inactivity, as this open task has been assigned for more than two years (see emails sent to assignee on May26 and Jun17, and T270544). Please assign this task to yourself again if you still realistically [plan to] work on this task - it would be very welcome!

(See https://www.mediawiki.org/wiki/Bug_management/Assignee_cleanup for tips how to best manage your individual work in Phabricator.)