Oof, that's some escalation of "you touched it, you own it" :-D

it looks to me like this is still a pending issue, and that a small patch to https://gerrit.wikimedia.org/g/mediawiki/core/+/472b691fb3dba77a298eb3a23fd2aa58edae75ba/includes/MediaWikiEntryPoint.php#354 to ass the Secure flag and also the SameSite attribute with "none" value, might do it. But I'm not at all familiar with ChronologyProtector, there could well be context I don't have.

After a chat with Aaron and discussion of the now abandoned patch: this feels to me like a design choice, that the global rootjob key should stay around until all jobs go, it's hard to know when the last one of those is, so just letting it expire via the TTL is fine. And the code does set a reasonable TTL, see https://gerrit.wikimedia.org/g/mediawiki/core/+/4cdbfe34377c132897e2348c6634705a32377006/includes/JobQueue/JobQueueRedis.php#462 and https://gerrit.wikimedia.org/g/mediawiki/core/+/4cdbfe34377c132897e2348c6634705a32377006/includes/JobQueue/JobQueue.php#66

This no longer seems to be the case; I guess that those table stats got updated sometime in the interim. Closing for now, if someone observes this again, it can be reopened.

Confirmed that this bug is fixed, so closing.

This package may not quite be abandoned now, see this thread: https://news-web.php.net/php.pear.qa/6151

Since PHP 8.2 support has been dropped (T358667), can this move forward now? :-)

Output from composer for this run:

Package operations: 3 installs, 14 updates, 50 removals
Installs: composer/installers:v2.3.0, symfony/polyfill-uuid:v1.37.0, symfony/polyfill-php83:v1.37.0
Updates: brick/math:0.17.1, bacon/bacon-qr-code:v3.1.1, firebase/php-jwt:v7.0.5, symfony/string:v7.3.8, symfony/type-info:v8.0.8, spomky-labs/pki-framework:1.4.2, web-auth/cose-lib:4.5.1, symfony/uid:v7.4.8, symfony/serializer:v7.4.8, symfony/property-info:v7.4.8, symfony/property-access:v7.4.8, symfony/clock:v7.4.8, spomky-labs/cbor-php:3.2.3, web-auth/webauthn-lib:5.2.5
Removals: wmde/php-vuejs-templating, wikimedia/textcat, wikimedia/testing-access-wrapper, wikimedia/metrics-platform, wikimedia/lucene-explain-parser, wikimedia/langconv, webonyx/graphql-php, symfony/var-dumper, symfony/validator, symfony/translation-contracts, symfony/translation, symfony/service-contracts, symfony/process, symfony/console, swaggest/json-diff, serialization/serialization, ruflin/elastica, react/promise, psy/psysh, psr/simple-cache, psr/http-server-middleware, psr/http-server-handler, pleonasm/bloom-filter, pimple/pimple, onoi/message-reporter, nyholm/dsn, nikic/php-parser, mustangostang/spyc, maxmind/web-service-common, maxmind-db/reader, league/uri-interfaces, league/uri-components, league/uri, league/oauth2-server, league/event, james-heinrich/getid3, geoip2/geoip2, ezimuel/ringphp, ezimuel/guzzlestreams, elasticsearch/elasticsearch, diff/diff, defuse/php-encryption, data-values/time, data-values/serialization, data-values/number, data-values/interfaces, data-values/geo, data-values/data-values, data-values/common, composer/ca-bundle

In T423779#11856779, @BBlack wrote:

Has the lazyPush thing from https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Translate/+/1277135 been tried yet? (I don't think so). Is it worth trying?

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-Core-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!