is this the same as T381128: backfillLocalAccounts.php should fill Client Hints?

No, the script doesn't try to copy client hints. It does try to copy IPs, it just (reportedly) doesn't always work.

In T394732#11063018, @Tgr wrote:

It does try to copy IPs, it just (reportedly) doesn't always work.

I scrolled through loginwiki:Special:Log/MediaWikiAccountBackfiller to find a current LTA account to test if the issue still exists: Loginwiki CU on GeorgezReevezPersonz (-> en:WP:LTA/GRP) shows the localhost IP, according to the CU tool there are ~2,680 other users on that IP.
CU on metawiki (where this sockpuppet registered) shows their real IP which is different (and consistent with previous IPs from this LTA).

In T394732#11063312, @Johannnes89 wrote:

In T394732#11063018, @Tgr wrote:

It does try to copy IPs, it just (reportedly) doesn't always work.

I scrolled through loginwiki:Special:Log/MediaWikiAccountBackfiller to find a current LTA account to test if the issue still exists: Loginwiki CU on GeorgezReevezPersonz (-> en:WP:LTA/GRP) shows the localhost IP, according to the CU tool there are ~2,680 other users on that IP.
CU on metawiki (where this sockpuppet registered) shows their real IP which is different (and consistent with previous IPs from this LTA).

Just encountered the issue again with https://login.wikimedia.org/wiki/Special:Contributions/Hide_on_Rosé_loses,_Timelash_winning

So apparently, when a global block is disabled on one wiki but remains active on Loginwiki, it could lead to this exact problem.

Just tested and confirmed this with https://meta.wikimedia.org/wiki/Special:CentralAuth/XXB_test_gjvcdg

Change #1225528 had a related patch set uploaded (by Arendpieter; author: Arendpieter):

[mediawiki/extensions/CheckUser@master] AccountCreationDetailsLookup: Include 'autocreate' log action in lookup

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

Change #1225528 merged by jenkins-bot:

[mediawiki/extensions/CheckUser@master] AccountCreationDetailsLookup: Include 'autocreate' log action in lookup

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

@Arendpieter Thanks for the patch. Your change looks correct to me, but just to clarify, it doesn't explain any of the recent examples given in the comments here, right? Or am I missing something?

In T394732#11521109, @matmarex wrote:

@Arendpieter Thanks for the patch. Your change looks correct to me, but just to clarify, it doesn't explain any of the recent examples given in the comments here, right? Or am I missing something?

As far as I understand, the home wiki is primarily determined by where the account was originally registered (attachedMethod = primary or new). However, if that information is missing, it falls back to the wiki with the most edits, which could be a wiki where the user was only autocreated.

backfillLocalAccounts.php runs on the loginwiki to create missing local accounts. It determines the user’s home wiki and then calls AccountCreationDetailsLookup->getAccountCreationIPAndUserAgent() against the home wiki’s database. getAccountCreationIPAndUserAgent() in turn calls getIPAndUserAgentFromDB(), which I patched. If backfillLocalAccounts.php can not retrieve data via AccountCreationDetailsLookup->getAccountCreationIPAndUserAgent(), it falls back to an incorrect IP.

But wait - you’re right. This cannot be the root cause, because even new accounts created by the backfill script show the wrong IP in loginwiki

Change #1226883 had a related patch set uploaded (by Arendpieter; author: Eugene Gvozdetsky):

[mediawiki/extensions/CentralAuth@master] Fix wrong IP logged in CheckUser for backfilled accounts

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

@matmarex I think I’ve now found the root of the problem. See https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CentralAuth/+/1226883

Change #1226883 merged by jenkins-bot:

[mediawiki/extensions/CentralAuth@master] Fix wrong IP logged in CheckUser for backfilled accounts

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

Interesting, I hope that helps. I don't know for sure if that will resolve the problem, but it seems plausible, and it shouldn't hurt. I guess we'll see once the patches are deployed (which should happen next week, see schedule: https://wikitech.wikimedia.org/wiki/Deployments/Train#Schedule).

Has this resolved the issue? Is the script now working correctly? Could one of the CheckUsers or stewards please check it?

In T394732#11610757, @Arendpieter wrote:

Has this resolved the issue? Is the script now working correctly? Could one of the CheckUsers or stewards please check it?

Seems to be working. Although there's a different issue now: The backfill script now appears in CU results – both in the indication how many accounts are sharing the IP and when checking the IP

I confirmed the issue with multiple LTA / spambots – the IP is correct every time, but every time the number of accounts is wrong due to MediaWikiAccountBackfiller appearing as another account sharing that IP.

In T394732#11612502, @Johannnes89 wrote:

Seems to be working. Although there's a different issue now: The backfill script now appears in CU results – both in the indication how many accounts are sharing the IP and when checking the IP

I confirmed the issue with multiple LTA / spambots – the IP is correct every time, but every time the number of accounts is wrong due to MediaWikiAccountBackfiller appearing as another account sharing that IP.

This has caused stewards accidentally locking MediaWikiAccountBackfiller a few months ago https://meta.wikimedia.org/w/index.php?title=User_talk:Elton&diff=prev&oldid=30086183#Special:CentralAuth/MediaWikiAccountBackfiller

Change #1288903 had a related patch set uploaded (by Arendpieter; author: Arendpieter):

[mediawiki/extensions/CentralAuth@master] Stop backfill script from appearing as account sharing IP in CheckUser

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

attemptAutoCreateLocalUserFromName() creates two newusers log entries:

• newusers/autocreate (from AuthManager::autoCreateUser) with setPerformer( $user ) — inserted only, without publish(), so no RecentChange is created. CheckUser's onLocalUserCreated callback writes one cu_log_event row attributed to the new user (correct).
• newusers/forcecreatelocal (from CentralAuthForcedLocalCreationService) with setPerformer( $performer ) (MediaWikiAccountBackfiller) — and it calls $logEntry->publish( $logId ). That creates a RecentChange, which CheckUserEventsHandler::onRecentChange_save turns into a cu_log_event row with cule_actor = MediaWikiAccountBackfiller and cule_ip_hex = <fake-session IP>.

I fixed this in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CentralAuth/+/1288903

Change #1288903 merged by jenkins-bot:

[mediawiki/extensions/CentralAuth@master] Stop backfill script from appearing as account sharing IP in CheckUser

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

@Johannnes89 (or anyone else) Could you check whether that patch resolved the problem?

In T394732#11973570, @matmarex wrote:

@Johannnes89 (or anyone else) Could you check whether that patch resolved the problem?

Looking at https://login.wikimedia.org/wiki/Special:Log/MediaWikiAccountBackfiller / https://meta.wikimedia.org/wiki/Special:Log/MediaWikiAccountBackfiller it appears the AccountBackfiller script has stopped working on May 20, probably as a result of that week's deployment train?

The bug still appeared in the early hours of Wednesday (but that was before the deployment train arrived)

@Johannnes89 You filtered the log by performer = MediaWikiAccountBackfiller. The only entry that ever carried that performer was the forcecreatelocal entry, which my commit deliberately eliminated. That was the whole point: to stop attributing a RecentChange to the backfiller so it would no longer pollute CheckUser.

So the MediaWikiAccountBackfiller log going empty around May 20 is the direct, intended consequence of the fix, not evidence that account creation stopped. The new autocreate entries are now filed under each newly created user’s name instead.

In T394732#11976270, @Arendpieter wrote:

@Johannnes89 You filtered the log by performer = MediaWikiAccountBackfiller. The only entry that ever carried that performer was the forcecreatelocal entry, which my commit deliberately eliminated. That was the whole point: to stop attributing a RecentChange to the backfiller so it would no longer pollute CheckUser.

So the MediaWikiAccountBackfiller log going empty around May 20 is the direct, intended consequence of the fix, not evidence that account creation stopped. The new autocreate entries are now filed under each newly created user’s name instead.

Ahh thanks. Is there an easy way to see backfilled accounts now? It's hard to test if the patch resolved the problem if I can't find a backfilled (LTA) account to test with 😬