I do not know, but the data engineering group owns the entire process and has done so for a good while now, so I should at the least be unassigned from this, I'll do that now.

It looks to me like attachbroken will only kick in if there is already a global account for the username (there is an entry in globaluser with gu_name being the same as the specified user name). I could be misreading the script though.

I don't see what was broken, when looking through the onUserSetEmail hook implementation in CentralAuth that is called when the user email is set locally. I also see no other reports of it being broken afterwards. Perhaps we can close and someone can re-open if it comes up again?

Still seeing these on 1.46.0-wmf.2.

Just to get one more data point: did you try it multiple times in Chrome and it always worked?

matmarex and I swapped duty weeks so he has it now and I'll get it next week.

Ran fixStuckGlobalRename.php and the job seems to be complete now, closing.

Looks like this is now complete, closing.

In T397789#10965717, @Novem_Linguae wrote:

<snip>

In my code editor, I have tooltips and intellisense turned on, so hovering over a parameter to see its definition elsewhere is easy.

Speaking just out of self-interest here, I would love this feature to be widely used for the simple sake of readability. I really appreciate reading a call fooSomething($page=blah, $user=blat, $showAll=true) instead of fooSomething(blah, blat, true). So whatever we can reasonably do to get to "widely used", I'm in favour of.

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

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.

There are public logs that describe the creation (automatic or other). And there is private information that could be reviewed, which is kept for 90 days, but I don't know that there's anything really of use in there.

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?

Hey @pmiazga can you remove the "Ariel" subscriber you added? That's my "created only for the NDA required for the Code of Conduct stuff" account, never used. And it sends notifications to my non-work email. I already get proper notification on this (work) account. Thanks!

In T391601#10730585, @RobH wrote:

@ArielGlenn,

Normally I turf these over to the SRE sub-team manager in charge of the server, but snapshot hosts are a slightly different beast than the rest (since I know the team handling them typically is just you and @Hokwelum) in the past.

If this isn't the case, and this should go to an SRE sub-team manager, please let me know!

Please review the checklist and fill it out for snapshot1017, then we'll schedule the migration. Thanks!

Added GlobalPreferences to the list after an IRC chat with Reedy.

I'd like to see named parameters used for boolean values a lot more often; there's nothing like reading code and encountering a bunch of calls like
somefunction( $nicelyNamedVar1, $nicelyNamedVar2, true, false )
and it's also pretty easy to screw up the order of bools passed in too. Named parameters give us the opportunity to make things a lot more readable, and safer as well.

Done, so closing.

Just to clarify why it was declined:

In T388564#10624852, @Clement_Goubert wrote:

@ArielGlenn I've created the CR to add the jobs to production, however there may be a need for a proper backfill since the job seems to only start at DAY-1? If it's the case, would you be open to running that backfill using mw-script-k8s to see if it works well under a kubernetes environment?

In T385866#10624052, @Clement_Goubert wrote:

...

Cross-referencing with the list of timers on mwmaint2002, it would seem that the backfillLocalAccounts jobs are not actually defined or ran at this moment. Is this an oversight that should be remedied, or does that mean they don't need to run?

@Tgr It looks like 3 of the screenshots might be restricted, as they are not viewable by me; the spots where those should appear are blank, just showing { F-number-here }

In T377140#10496666, @JTweed-WMF wrote:

Do we actually want to do this? I'm not sure that we do.

If there are problems after rolling out, we should be rolling back, fixing and trying again. Not letting people opt out.

Never mind, bad copy paste, wrong file, etc. I'll just see myself out now...

In production the table has

| global_preferences | CREATE TABLE `global_preferences` (
  `gp_user` int(10) unsigned NOT NULL,
  `gp_property` varbinary(255) NOT NULL,
  `gp_value` blob DEFAULT NULL,
  PRIMARY KEY (`gp_user`,`gp_property`),
  KEY `global_preferences_property` (`gp_property`)
) ENGINE=InnoDB DEFAULT CHARSET=binary

so I imagine that the sql in the extension ought to have gp_property varbinary(255) NOT NULL as well.

Created and running so this task can definitely be closed.

Nothing reported, so that's a wrap.

In T381128#10367581, @kostajh wrote:

Is this something that MediaWiki-Platform-Team can do, in scope of your existing work around T378401? (Otherwise, I'm not sure when TSP would have time to get to it.)

This script is now live in production. I'll leave the task open for a day so we can make sure nothing strange happens.

I've done a test dry run of the current version of the script, to backfill one day's worth of missing local accounts on loginwiki. The mix included some accounts created by stewards, some accounts that were locally created elsewhere by the user themselves, and one interesting wikitech merged account from some years back.

Just to clarify: I think both the service and the maintenance script are ready for last "fix this please" or merge, since the requested functionality for stewards is present.

@Urbanecm subscribed, tyvm!

Okay, the script has been updated to deal with account creations by other performers, if the IP/User Agent for those performers can be found, and to skip creation of accounts for any where the info is no longer available.

@JJMC89 Can I get your opinion on the above (Urbanecm's comment)? I want to make sure we are meeting everyone's needs here before we roll this out. Thanks!

The above two patches, or something like them, might be able to handle the case of forced user creations by others. Leaving them here for comment and discussion.

In T378401#10307273, @Tgr wrote:

...

I don't think it's worth the effort though. I think it's fine to just let such cases fail and log the failure. If we want to be honest, no one ever looks at maintenance script error output anyway.

In T378401#10307169, @JJMC89 wrote:

In T378401#10303452, @ArielGlenn wrote:

there were several failures, because the IP address for the user had been globally blocked with reason 'no open proxies'.

How/where are these accounts getting created in the first place if the IP is blocked?

The remaining 35 or so got the IP of 127.0.0.1 and an empty user agent string, because those accounts had all been force created by an admin responding to https://en.wikipedia.org/wiki/Wikipedia:Request_an_account

Are you fetching the correct data? These should have real IPs/UAs from the person that created the account.

To skip over temp account names and not attemp to create them until they are enabled on metawiki and loginwiki, we'd need to update InitialiseSettings.php to set $wgAutoCreateTempUser['known'] to true for those wikis, so that temp names will be recognized (otherwise we get a blanket false response from the check). Is that okay?

One more comment:: do we want to check for global blocks in advance before trying to autocreate?

I ran with '2 hours ago' and it was fine. One user was autocreated with an appropriate IP and user agent.

Did some dry runs for loginwiki backfill. Results:

• for one day's worth, 10622 uids checked, 44 accounts would be created.
• for 7 days, 52582 uids checked, 232 accounts would be created, of which two were temporary accounts and would fail.
• for 2 hours, 709 uids checked and two accounts would be created.

All dry runs took less than ten minutes.

I have a patch ready but no point in pushing it up before the script lands via the train. Maybe I'll just claim this task in advance anyways. Swipe!

@Tgr --startdate "5 days ago" works as expected, you're all set already.

I have a question about the change made here https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CheckUser/+/1073764

In T373789#10112786, @Jdforrester-WMF wrote:

I've worked around it for now by manually editing composer.json to pin version 1.1.4, but that is not ideal.

Which composer.json? MediaWiki provides psr/log, which is pinned to 1.1.4, and has been since we upgraded it in 2021.

core composer.json asks for 1.1.4. It may be that I ran composer incorrectly, but for whatever reason, the version in the checkuser vendors directory was a 3.x one.

Encountered when testing https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CheckUser/+/1067385 for https://phabricator.wikimedia.org/T371267

In T373447#10096967, @matmarex wrote:

I thought it was intentional.

The patch currently up is missing the CheckUser related stuff, it's just bare bones.

In T371267#10023454, @Dreamy_Jazz wrote:

...

As to other mitigations we could:

• Fetch the correct IP, user agent, and timestamp by finding it on the wiki where the user was actually created. Then it would appear in CheckUser as if the account was autocreated normally.
• Add some kind of flag to indicate that this was created by a backfill script (such as a custom user agent string that says Backfill creation by maintenance script)

In T371267#10027610, @Niharika wrote:

@ArielGlenn Hi there! Hope you're doing well. We are still a bit far from deploying to any major production wikis (1-2 quarters possibly). It's hard to put any firm dates around this because of multiple dependencies on other teams and on Legal. We haven't decided on which wikis we will pilot on either.

Hey @Dreamy_Jazz can you point me to some sort of schedule as to the rollout? I'm not interested in hard dates, just getting a general sense of the order and time frame.

After discussion during the weekly team meeting, we decided that further work on this task is not warranted, so closing. Next steps will be in a separate task for doing the backfill.

I can find insertion metrics for local account creation in prometheus (though apparently not per wiki, so that's a problem), but I can't seem to find a topic for retries or failures. Sample link for that, so we have it: https://prometheus-eqiad.wikimedia.org/ops/graph?g0.expr=kafka_server_BrokerTopicMetrics_MessagesIn_total%7Btopic%3D%22eqiad.mediawiki.job.CentralAuthCreateLocalAccountJob%22%7D&g0.tab=1&g0.stacked=0&g0.show_exemplars=0&g0.range_input=1h&g0.end_input=2024-07-29%2012%3A00%3A20&g0.moment_input=2024-07-29%2012%3A00%3A20

Checking metawiki for the same accounts created on enwiki for the same uid range as earlier, there's about 620 that were globally registered in July that have no accounts on metawiki. So that's somewhat worse than loginwiki, though still a small number.

So, of the 140 accounts created on enwiki in the last 30 days, no entry on loginwiki, and having an entry in the globalusers table made in the last 30 days, about half of those were created on behalf of the user by an admin. I'll have a look at a good chunk of the rest to see if there's anything interesting about those other 70-ish accounts.

At least some of the problematic names are accounts that were created on behalf of a user by another user, via https://en.wikipedia.org/wiki/Wikipedia:Request_an_account/Guide (see code at https://github.com/enwikipedia-acc/waca/tree/rel7.17 )

There are three open tasks referencing some sort of failure with this job, no idea if any are relevant now, but listing them here just in case:
T220769: Account created without having a loginwiki or metawiki automatically created (2019)
T306636: DBQueryError: Error 1213: Deadlock found in UserOptionsManager::saveOptionsInternal (2022)
T173451: New accounts not being reliably created on loginwiki (2017)

Okay, I checked accounts created during the last approximately 30 days on enwiki. There were about 134700 users created; about 400 of those had no entry in the loginwiki user table, but they all had entries in the globaluser table (looking entries up on loginwiki and globaluser by name).

I've done some simple spot checks, looking at recent account creation on en wiki vs accounts on loginwiki, and it's good so far, but that's small amounts of data. Working on getting a more comprehensive check for say a 30 day period, we'll see what it shows.

Hey Daniel, I'd just assumed that getting added to the analytics-privatedata-users group would be redundant so thanks for catching that.

What are the next steps on this? Any information I need to provide, or anyone I should nudge?