I think this is caused by SUL3 being enabled on test.wikipedia.org. My reasoning:

• Since T383729: SUL3 Phase 0: Account creation and login on test wikis, test.wikipedia has SUL3 enabled for all users.
• During the authentication, most extensions (including GrowthExperiments) are disabled, cf. configuration.
• Having Growth features depends on onLocalUserCreated hook firing.
• onLocalUserCreated hook is expected to run directly after the user has been created and as such, I presume it is fired while the user is still on auth.wikimedia.org. Because GrowthExperiments is disabled while at auth.wikimedia.org (see above), its implementation of the hook does not have a chance to run, resulting in the Growth features not being enabled.

@Tgr might have this on his mind already, see T364866#10230679.

Yeah, it's sort of expected; I thought we can address this between rolling out to testwikis and group 0 wikis, which in hindsight was a bad idea since testwikis are used for QA by some teams. Sorry for the disruption.

I don't have any great idea on what to do about it, other than introducing a new hook (CentralAuthLocalUserCreated or something - the same is already done for PostLoginRedirect).

In T384236#10477887, @Tgr wrote:

I don't have any great idea on what to do about it, other than introducing a new hook (CentralAuthLocalUserCreated or something - the same is already done for PostLoginRedirect).

I don't really like that idea, because it would mean extensions would essentially have to listen for two hooks in order to do one job. What about not invoking onLocalUserCreated immediately, but within a job? That way, we could do a switch back to the regular wiki environment (outside of auth.wikimedia.org), and the hook should operate normally (transparently for the extension). Alternatively, maybe an internal API request could be used to do the switch?

A boring but simple solution would be to just enable GrowthExperiments on the local domain. We restrict extensions to limit the security footprint, but there isn't much risk to having them.

In T384236#10477951, @Urbanecm_WMF wrote:

What about not invoking onLocalUserCreated immediately, but within a job?

That works in terms of using the normal configuration, but that means the effects of LocalUserCreated get delayed. At the minimum that would be a breaking change, and I suspect problematic to many use cases (including GrowthExperiments, since the job wouldn't have run yet at the point where the extension needs to decide how to handle the freshly signed-up user).

Alternatively, maybe an internal API request could be used to do the switch?

Making MediaWiki core do internal API requests just to account for Wikimedia-specific hacks wouldn't be great.

A boring but simple solution would be to just enable GrowthExperiments on the local domain. We restrict extensions to limit the security footprint, but there isn't much risk to having them.

Hey @Tgr, it appears like GrowthExperiments was caught off guard by the decision in T373737 to disable extensions that are deemed irrelevant on the SUL 3 login domain. Is there a process that is in place to determine which extensions get disabled and which ones don't?

I have a feeling that this sort of sudden realisation may continue to happen on other teams who's extensions rely on the hooks that run during the authentication process.

Change #1115369 had a related patch set uploaded (by Gergő Tisza; author: Gergő Tisza):

[operations/mediawiki-config@master] Do not disable extensions on SUL3 shared authentication domain

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

Change #1115369 merged by jenkins-bot:

[operations/mediawiki-config@master] Do not disable extensions on SUL3 shared authentication domain

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

Mentioned in SAL (#wikimedia-operations) [2025-01-30T21:10:42Z] <tgr@deploy2002> Started scap sync-world: Backport for [[gerrit:1115369|Do not disable extensions on SUL3 shared authentication domain (T373737 T384919 T384236)]]

Mentioned in SAL (#wikimedia-operations) [2025-01-30T21:13:29Z] <tgr@deploy2002> tgr: Backport for [[gerrit:1115369|Do not disable extensions on SUL3 shared authentication domain (T373737 T384919 T384236)]] synced to the testservers (https://wikitech.wikimedia.org/wiki/Mwdebug)

Mentioned in SAL (#wikimedia-operations) [2025-01-30T21:23:24Z] <tgr@deploy2002> Finished scap sync-world: Backport for [[gerrit:1115369|Do not disable extensions on SUL3 shared authentication domain (T373737 T384919 T384236)]] (duration: 12m 42s)

In T384236#10503686, @DMburugu wrote:

Is there a process that is in place to determine which extensions get disabled and which ones don't?

The process was basically "look hard at the list of extensions and try to figure out which ones are important for login". But after some more in-depth code review of things that could possibly go wrong, I'm giving up on disabling extensions entirely.

Pulling to sprint for QA.

In T384236#10511844, @Urbanecm_WMF wrote:

Pulling to sprint for QA.

Note there's a patch in T364866 that's not merged yet that will probably be needed for the welcome survey to work.

Checked on testwiki wmf.14 - so far works as before (and as expected):

• on Main page a user clicks on Create an account
• upon creating an account a user is presented with a guided tour

• clicking on the username link directs a user to Special:Homepage

The banner for the Welcome survey is present (it's new to me - assuming it's acceptable behavior.

@Tgr - I'll will keep an eye on T364866 (as mentioned in https://phabricator.wikimedia.org/T384236#10512137). Thx!

(The fix for the hook issue was backported to all production wikis on Monday, so everything should work properly now.)

In T384236#10541321, @Tgr wrote:

(The fix for the hook issue was backported to all production wikis on Monday, so everything should work properly now.)

@Tgr: To clarify, does this refer to the onLocalUserCreated hook? Because 1.44.0-wmf.16 group1 in in T386171 is seeing a lot of Error 1146: Table 'centralauth.logging' doesn't exist errors called from Function: MediaWiki\CheckUser\HookHandler\CheckUserPrivateEventsHandler::onLocalUserCreated

No, I was referring to rECAUbbf811d96960: Fire CentralAuthPostLoginRedirect on SUL3 login.