Spent the better part of the day rolling back those changes, after restoring both the original database, and directory structure, I updated git checkout to REL1_35, updated composer, ran cleanupUsersWithNoId.php, then followed that by update.php.

Final result for the day..... Wiki is on 1.35.9 (06eb08d)

It seems the script is not running by the updater, but mention in the release notes to be run.

=== Configuration changes in 1.31 ===
[...]
* Wikis that contain imported revisions or CentralAuth global blocks should run
  maintenance/cleanupUsersWithNoId.php.
[...]

So if your wiki is working after that run, is this is a bug or it is already documented?
Maybe the updater needs a check step to die if the script was not running? (So running a dry mode in updater and report failure)

I am not on 1.39 yet, I would NOT call this already documented. the upgrade.php should either invoke the cleanupUsersWithNoId.php or should not run. failing to do so is a destructive upgrade, that multiple users have encountered.

That was also requested in T232273: update.php should maybe run cleanupUsersWithNoId.php

Sounds actor migration related, but that's supposed to happen between 1.31 and 1.35.

What did the DB you started with look like, was rev_actor already populated? What's it like after successfully upgrading to 1.35?

In T326071#8493307, @Betacommand wrote:

Spent the better part of the day rolling back those changes, after restoring both the original database, and directory structure, I updated git checkout to REL1_35, updated composer, ran cleanupUsersWithNoId.php, then followed that by update.php.

I'm not sure cleanupUsersWithNoId.php is relevant to this, that's about users with a 0 user ID, not a 0 actor ID.

Note that the revision table was a 2-step migration.

• Originally, user information was stored on revision table, on rev_user and rev_user_text fields. No actor table existed.
• On 1.31, the revision_actor_temp_table was created with the revactor_actor field. But it wasn't being used by default until 1.33. See also $wgActorTableSchemaMigrationStage.
• On 1.39, the revision_actor_temp_table is no longer used and the actor is stored in the revision table, in the rev_actor field.

I fear migrating from before 1.33 straight into 1.39 may cause the intermediate migration of actors from the revision table to be missed.

Maybe an upgrade script was dropped per T259771: RFC: Drop support for older database upgrades? I guess that would be a wontfix then, per that policy. Although we really should prevent the installer from running when the old version is more than one LTS period away, instead of running and probably messing up everything.

@Tgr Not sure if cleanupUsersWithNoId.php will actually do anything, but I figured Id document everything.

The root issue is that when I initially upgraded to 1.39 rev_actor was set to 0 for ALL edits. I have no clue what interactions/changes happened between 1.32 and .39 that would have caused rev_actor = 0, but Im just documenting what I see/do to help others identify this issue since I am not the first person with this problem. When I get a couple of hours free I will finish the .35 => .39 upgrade and post my notes for that too.

I would like to mention commit 24115a8f4cc0f079f30894bc07eb7476f2dffb3e, it removed the revision_actor_temp table, but the maintenance script was not updated and still try to write to that table rather than the rev_actor field of revision table.

Change 874466 had a related patch set uploaded (by Func; author: Func):

[mediawiki/core@REL1_39] MigrateActors: Write to revsion table (Follow-up 24115a8)

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

In T326071#8494088, @Tgr wrote:

Maybe an upgrade script was dropped per T259771: RFC: Drop support for older database upgrades? I guess that would be a wontfix then, per that policy. Although we really should prevent the installer from running when the old version is more than one LTS period away, instead of running and probably messing up everything.

1.31 to 1.39 is a supported jump according to that decision, as is anything in the interim to 1.39.

Change 874466 merged by jenkins-bot:

[mediawiki/core@REL1_39] MigrateActors: Write to revsion table (Follow-up 24115a8)

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

After studying the log provided in T326071#8493256, I found that the problem is bigger than I thought.
The problematic change would destroy the database when updating from versions before 1.33, though not in the way mentioned in T326071#8493877.

Further fixes are needed, the patch-revision-actor-comment-MCR.sql should be split into serval files and executed in different times.
Currently, it will drop a lot of fields including rev_user and rev_user_text before migrating, which is unacceptable.
Some should be dropped at least after migrateActors (section 1.31), and some should be after populateContentTables (section 1.32).

Change 874878 had a related patch set uploaded (by Func; author: Func):

[mediawiki/core@REL1_39] [WIP] Fix T326071

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

Change 874878 had a related patch set uploaded (by Func; author: Func):

[mediawiki/core@REL1_39] installer: Split drop action out of the SQL patch for actor migration

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

I got this error upgrading from 1.32.2 to 1.39.1 and have spent better part of a day trying to find the reason before stumbling on this page. I notice that there is a warning about this issue on the 'Upgrade to 1.39 page' but not on the 'Upgrade to 1.39.1' page. There need to be a warning there as well.

I ran into this same problem when I upgraded from 1.31 and was very unpleasantly surprised.

The Manual:Upgrading page says that "Since Version 1.36, MediaWiki only commits to supporting upgrades from two LTS releases ago". Which should include 1.31 to 1.39, so I was not expecting this at all.

Please remove that claim or add a caveat, or reinstate the migration code.

I worked around this bug by first updating to 1.35.9 and then to 1.39.1

I copied the warning from the 1.39 page to the upgrading to 1.39.1 page as a stopgap.

In T326071#8518928, @Ovvldc wrote:

I copied the warning from the 1.39 page to the upgrading to 1.39.1 page as a stopgap.

Good job, I should have done that myself. (I didn't realise I could.)

Change 874878 merged by jenkins-bot:

[mediawiki/core@REL1_39] installer: Split drop action out of the SQL patch for actor migration

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

Is the "solution" posted in https://www.mediawiki.org/wiki/Topic:X82t27s2f03nf8h8 one that could retroactively be implemented as a maintenance script? In my case I think I noticed this way too late to revert to any prior MW installation or backup point and do an "orderly" sequence of upgrade jumps, so this info is either lost and my database corrupt or I manually fix some of the actor IDs or - ideally - this could be a scripted database fix that goes through all these faulty tables and (re) assigns actor IDs to make all these pages work again (in my cases it applies to a lot of files as well, that now cannot be edited, deleted or re-uploaded.. but they're still there)

In T326071#8552670, @Rebastion2 wrote:

Is the "solution" posted in https://www.mediawiki.org/wiki/Topic:X82t27s2f03nf8h8 one that could retroactively be implemented as a maintenance script?

That will just assign your entire revision history to the same fake user. I don't know if that's useful as a script.

(That said, much of the ActorStore/RevisionStore logic already tries to do that: RevisionStore::newRevisionFromRow and similar methods will assign to the system user Unknown user if the referenced actor doesn't exist. I wonder why that does not work here.)

@Func this is fully fixed now and just waiting for a point release, right?

In T326071#8556045, @Tgr wrote:

@Func this is fully fixed now and just waiting for a point release, right?

Yes, I tested with MySQL, and everything works.

Will this also fix
https://www.mediawiki.org/wiki/Topic:Xax6icrhocnukdil
or https://www.mediawiki.org/wiki/Topic:Xb6jo5wtk8ph98ak
?

In T326071#8556108, @Func wrote:

Yes, I tested with MySQL, and everything works.

Great, thank you!

In T326071#8558808, @Rebastion2 wrote:

Will this also fix
https://www.mediawiki.org/wiki/Topic:Xax6icrhocnukdil

Probably not, this issue would affect every single revision, and that user is complaining about a single page (and seems to say the wiki is on 1.38).

BTW that discussion mentioned findMissingActors.php which does seem like it would make a wiki affected by this bug work again (by assigning all edits to Unknown user, which I guess is the best that can be achieved without DB dumps from before the failed upgrade).

or https://www.mediawiki.org/wiki/Topic:Xb6jo5wtk8ph98ak

Seems likely.

I get errors very reminiscent of this problem when I try to use the refreshlinks.php maintenance script in the new version 1.39.2. Is that coincidence, or is the bug still somewhere? And if so, do I need to open a new bug?

In T326071#8657491, @Ovvldc wrote:

I get errors very reminiscent of this problem when I try to use the refreshlinks.php maintenance script in the new version 1.39.2. Is that coincidence, or is the bug still somewhere? And if so, do I need to open a new bug?

The previous version would break your database, that's an unrecoverable data loss, this new release wouldn't fix that magically.

If not the case, feel free to paste the console output and/or error logs here.

I know, I had to restore my database from a backup, and then upgrade in steps. It was annoying. But Mediawiki runs fine, except that the maintenance script gives errors:

maintenance username$ php refreshlinks.php
Refreshing redirects table.
Starting from page_id 1 of 2536.
100
200
300
400
500
600
700
800
900
1000
1100
1200
1300
1400
1500
1600
1700
1800
1900
2000
2100
2200
2300
2400
2500
Refreshing links tables.
Starting from page_id 1 of 2536.
InvalidArgumentException from line 168 of /Library/WebServer/Documents/wiki/includes/user/ActorStore.php: Actor name can not be empty for 0 and 9
#0 /Library/WebServer/Documents/wiki/includes/Revision/RevisionStore.php(1801): MediaWiki\User\ActorStore->newActorFromRowFields(0, '', '9')
#1 [internal function]: MediaWiki\Revision\RevisionStore->MediaWiki\Revision\{closure}(6789)
#2 /Library/WebServer/Documents/wiki/includes/Revision/RevisionStoreCacheRecord.php(104): call_user_func(Object(Closure), 6789)
#3 /Library/WebServer/Documents/wiki/includes/Revision/RevisionStoreCacheRecord.php(93): MediaWiki\Revision\RevisionStoreCacheRecord->loadFreshRow()
#4 /Library/WebServer/Documents/wiki/includes/page/WikiPage.php(2132): MediaWiki\Revision\RevisionStoreCacheRecord->getUser(3)
#5 /Library/WebServer/Documents/wiki/maintenance/refreshlinks.php(281): WikiPage->doSecondaryDataUpdates(Array)
#6 /Library/WebServer/Documents/wiki/maintenance/refreshlinks.php(203): RefreshLinks::fixLinksFromArticle(4, false)
#7 /Library/WebServer/Documents/wiki/maintenance/refreshlinks.php(87): RefreshLinks->doRefreshLinks(1, false, '2536', false, false)
#8 /Library/WebServer/Documents/wiki/maintenance/includes/MaintenanceRunner.php(309): RefreshLinks->execute()
#9 /Library/WebServer/Documents/wiki/maintenance/doMaintenance.php(85): MediaWiki\Maintenance\MaintenanceRunner->run()
#10 /Library/WebServer/Documents/wiki/maintenance/refreshlinks.php(499): require_once('/Library/WebSer...')
#11 {main}

That should be a separate bug. This one is about broken DDL commands causing the data in entire DB columns to be lost. Your issue sounds like the migration erroring out because of incorrect data in some user-related field. (T307738: Actor name can not be empty for 0 and 3215898 is similar but how broken user rows are handled in a migration vs. a web request seem like different enough problems.)

Note that at the time of writing the documentation says

Do not upgrade from a MediaWiki version older than 1.33 to MediaWiki 1.39.1, or you may lose data! Upgrade to 1.35 first. See task T326071.

• https://www.mediawiki.org/w/index.php?title=Manual:Upgrading&oldid=6362610

But as far as I can see here, probably 1.39.2+ works. So maybe we should update a bit the message (?)

Do not upgrade from a MediaWiki version older than 1.33 to MediaWiki <= 1.39.1, or you may lose data! Upgrade to 1.35 first. Or, upgrade to 1.39.2+. See task T326071.