This seems very similar/related to T220769.

Thank you Framawiki for this task. Thank you Three_Sixty for the link to T220769. I've read T220769 and related tasks.

In T371267, @Tgr wrote:

Older accounts are not in scope for this task. In any case, I very much doubt we still retain IP information for them.

@Tgr, where is the task to repair older accounts? Is it T220769?

In T385866, @ArielGlenn wrote:

They certainly do need to run; if the timer isn't set up right, that's my oversight in the original patch. And that's both on metawiki and loginwiki.

@ArielGlenn, when was centralauth-backfillLocalAccounts.php-loginwiki run for the last time? When was centralauth-backfillLocalAccounts.php-metawiki run for the last time? What is their future schedule?

In T393656#10803363, @NicoScribe wrote:

<snip>

@ArielGlenn, when was centralauth-backfillLocalAccounts.php-loginwiki run for the last time? When was centralauth-backfillLocalAccounts.php-metawiki run for the last time? What is their future schedule?

These backfill jobs curently run for loginwiki and metawiki multiple times each day, covering the last 24 hours. The backfill may fail for an account for specific reasons (eg. a blocked IP range).

Thanks @ArielGlenn!
So the backfill jobs have been run several times to repair the following cases. Do you have logs showing the cause, when a backfill fails?
1 account for https://meta.wikimedia.org/wiki/Special:CentralAuth/Jenikipedia
2 accounts for https://meta.wikimedia.org/wiki/Special:CentralAuth/Furkan2525
2 accounts for https://meta.wikimedia.org/wiki/Special:CentralAuth/Nisapro
2 accounts for https://meta.wikimedia.org/wiki/Special:CentralAuth/Robertlanelilly
2 accounts for https://meta.wikimedia.org/wiki/Special:CentralAuth/Robertlane2031
2 accounts for https://meta.wikimedia.org/wiki/Special:CentralAuth/Fjshuxicjeb1
2 accounts for https://meta.wikimedia.org/wiki/Special:CentralAuth/BobDobolina1

Maybe we should pass UltimateAuthority as the performer for the backfill script. Not 100% sure about meta, but at least on loginwiki I imagine we'd prefer the account to be created, even if it's blocked or prevented by some other rule.

In T393656#10803363, @NicoScribe wrote:

Thank you Framawiki for this task. Thank you Three_Sixty for the link to T220769. I've read T220769 and related tasks.
@Tgr, where is the task to repair older accounts? Is it T220769?

There is no such task. What would be the point? Checkuser data only goes back 90 days.

Thank you @Tgr. Well, I am sorry, I thought that the accounts on loginwiki and metawiki were useful for other things (loginwiki for accounts synchronization when a user visit several wikis, and metawiki for OAuth use, with $wgMWOAuthCentralWiki in CommonSettings.php).

We are not using loginwiki for account synchronization anymore. OAuth is indeed one of the reasons meta was added as an autocreate wiki, but it's pretty rare for a missing account to cause problems, and accounts get autocreated whenever you visit the wiki while being logged in, so even when it is a problem it is self-healing. I don't think it's worth trying to fix retroactively.

One small note: users without metawiki account are much more common than users without loginwiki account.

• Hideo71, Andrepalma1, VidyaVenkat34, RachelMichelleTiller, Acharya sushil, Memenitalya, ComedyFan20013, Stepanyancycling, Orbital flowerz, found between 05:23, 9 May 2025 and 20:27, 8 May 2025
• MireilleBH123, Esthetio found between 17:46, 7 May 2025 and 14:11, 6 May 2025

In T393656#10808742, @NicoScribe wrote:

One small note: users without metawiki account are much more common than users without loginwiki account.

Probably because there are more locally blocked IPs on metawiki than loginwiki. Accounts can't be autocreated on a blocked IP.

Historically it's because everyone visited loginwiki sooner or later (as part of central login) if they stayed active for a while, and the account got autocreated at that point.
Going forward, that's not the case anymore, but we have a backfill script, so it shouldn't matter one way or another.

https://phabricator.wikimedia.org/T378401#10307273 for more about the backfill script and what it skips when doing autocreates; this can be revisited if appropriate.

I think this is ultimately a question for stewards, as they are the target audience for these autocreations: when a user registers successfully on some wiki, but their local account on metawiki and/or loginwiki cannot be created because of some local rule (block, abusefilter etc), what would be your preferred outcome for the backfill script (T371267: Create a script to backfill missing local accounts on loginwiki/metawiki for new global accounts)? Obeying the rule or overriding it and creating the account anyway?

As I said on discord: Accounts created by the backfill script show the wrong IP in loginwiki CU. The backfill script has little value to stewards as long as that's the case.

In T393656#10832792, @Johannnes89 wrote:

As I said on discord: Accounts created by the backfill script show the wrong IP in loginwiki CU. The backfill script has little value to stewards as long as that's the case.

Filed as T394732: backfillLocalAccounts.php does not (always?) copy checkuser data.

In T393656#10813439, @Tgr wrote:

I think this is ultimately a question for stewards, as they are the target audience for these autocreations: when a user registers successfully on some wiki, but their local account on metawiki and/or loginwiki cannot be created because of some local rule (block, abusefilter etc), what would be your preferred outcome for the backfill script (T371267: Create a script to backfill missing local accounts on loginwiki/metawiki for new global accounts)? Obeying the rule or overriding it and creating the account anyway?

Filed T394733: Consider ignoring permission checks in backfillLocalAccounts.php to follow up on that. (In hindsight maybe I should just have reworded this task. Oh well.)

I think what's left here is to spot-check some examples and confirm they are failing due to permission checks. If that's the case, this task can be closed as invalid (since that's the expected behavior) and we can follow up in T394733 on whether we want to change that.

I'll take a look at the specific examples and see what the problem might be, before the checkuser data disappears.

I've seen this happening again this week

Example: