Page MenuHomePhabricator

Run maintenance/cleanupUsersWithNoId.php on beta testwiki
Open, Needs TriagePublic

Description

https://integration.wikimedia.org/ci/job/beta-update-databases-eqiad/37538/console

Lots of: User name "File Upload Bot (Magnus Manske)" is usable, cannot create an anonymous actor for it. Run maintenance/cleanupUsersWithNoId.php to fix this situation.

Not sure if just mwscript maintenance/cleanupUsersWithNoId.php --wiki=testwiki would fix this, or the script needs to run with one of the options it has.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptOct 20 2019, 11:38 AM

Ping to @Anomie as I think he has the most experience with this task.

You need to supply --prefix, and you might want to use --assign too.

--prefix is used to prefix the usernames for the problematic imported edits. If it matches a valid interwiki prefix on the wiki, the usernames will be linked accordingly in page history and so on. If it doesn't match, the names will be displayed without being linked. IIRC when running it for production we used --prefix=imported. You can see some examples of both linked and unlinked names in https://test.wikipedia.org/w/index.php?title=Template:R_template-protected&action=history for example.

--assign will make it assign revisions with names of existing users (local or SUL) to those users. Omitting it will result in all the usernames on affected rows being prefixed. Whether you use it or not basically comes down to whether you think it's likely that the affected revisions were all imported from production and that matching names between production and beta are the same user.

Thanks @Anomie for the detailed reply. I think we should wait until T235970: beta testwiki site is broken: "Unknown database 'testwikidatawiki'" is resolved as the wiki is not readable at this moment.

Mentioned in SAL (#wikimedia-releng) [2019-12-19T13:20:19Z] <James_F> [BETA CLUSTER] mwscript maintenance/cleanupUsersWithNoId.php --wiki=testwiki --prefix=imported T235971

This should now be resolved, if it's still an issue?

Thanks. I guess we'll need to wait and watch Jenkins logs for further reappearances?