@Nikerabbit @Addshore When your respective teams are investigating this and if you need help with how the constraint works and how it is typically dealt with, you'll probably want to tag Platform Engineering as they know this code fairly well (and better than me).

I do remember adding the StubObject::unstub( $wgLang ); for T214358: Fatal error: Uncaught TypeError: Argument 2 passed to TranslateHooks::onPageContentLanguage() must be an instance of Language, string given. A few extensions are using it when setting the value in the hook while avoiding using request globals directly.

What for does purging need to know the page language? For language variants.

Since this is a newly created user, it doesn't seem necessary to purge the user pages, or maybe the user pages do not need to be purged for every option change. Just for a gender change?

I might be very wrong here but can it be that it's caused by I7ca40f8eda?

I highly doubt this is something Wikibase team would be able to fix. The usage of the LocalUserCreated hook in Wikibase code seems to be straightforward and simple, something in core or Translate extension needs to change. It might be caused by splitting Language object. I add Daniel and CPT to the ticket.

The stack trace reads like a fun chain of lazy initialization logic causing a User object to be loaded prematurely. There are several places where this chain could potentially be cut, but I didn't find a trivial once at a first glance. I'm wondering though why the User object has to be loaded when a new user has just been created. Also, why is autoCreateUser() triggered before setup is complete? Lots of potential problems & solutions.

User::saveSettings is calling Title::purgeSquid. It is undocumented why changing preferences requires purging the user page, unconditionally, synchronously.

It was added in r42179 with reference to T3306: Suppress the "email this user" link in the toolbox if said user has opted not to/can't receive emails. It seems the purge is intended to update the state of the "Email user" link when the associated preference is changed.

But the speculation about purging for gender changes might now be another use case requiring such a purge.

In T240083#5731759, @daniel wrote:

There are several places where this chain could potentially be cut, but I didn't find a trivial once at a first glance.

ContentHandler::getPageLanguage() probably shouldn't depend on the request in the first place. If the content is really in multiple languages somehow such that it can be displayed in the user's UI language, that should probably be indicated directly for the caller to deal with (if it cares) instead of returning the current user's UI language. As it is, this particular use case (getCdnUrls) is broken because it won't be returning every possible URL, only those corresponding to the current user's UI language. But changing all that would probably be a large project.

Possibly the simplest place is here

public function purgeSquid() {
    DeferredUpdates::addUpdate(
        new CdnCacheUpdate( $this->getCdnUrls() ),
        DeferredUpdates::PRESEND
    );
}

It's already deferring the actual update, you'd just have to somehow move the call to $this->getCdnUrls() to when the update runs instead of when it's constructed.

Also, why is autoCreateUser() triggered before setup is complete?

Part of setup is determining the User making the request. If that User doesn't exist locally yet, it has to be auto-created to have it available to finish the setup.

In T240083#5732326, @Anomie wrote:

User::saveSettings is calling Title::purgeSquid. It is undocumented why changing preferences requires purging the user page, unconditionally, synchronously.

It was added in r42179 with reference to T3306: Suppress the "email this user" link in the toolbox if said user has opted not to/can't receive emails. It seems the purge is intended to update the state of the "Email user" link when the associated preference is changed.

"Email user" isn't shown for anonymous visitors, right? So it's not in the web cache, so purgeSquid() isn't needed. Never was, as far as I understand...

But the speculation about purging for gender changes might now be another use case requiring such a purge.

That may indeed be needed, but shouldn't have anything to do with purging web caches.

In T240083#5731759, @daniel wrote:

There are several places where this chain could potentially be cut, but I didn't find a trivial once at a first glance.

ContentHandler::getPageLanguage() probably shouldn't depend on the request in the first place. If the content is really in multiple languages somehow such that it can be displayed in the user's UI language, that should probably be indicated directly for the caller to deal with (if it cares) instead of returning the current user's UI language. As it is, this particular use case (getCdnUrls) is broken because it won't be returning every possible URL, only those corresponding to the current user's UI language. But changing all that would probably be a large project.

Yes, the concept of page languages as currently implemented is broken. When I created ContentHandler, I tried to keep the existing behavior, baking the existing confusion into the interface of ContentHandler. Would have been better to fix it.

It's already deferring the actual update, you'd just have to somehow move the call to $this->getCdnUrls() to when the update runs instead of when it's constructed.

Or make the list of URLs not depend on the user. As you point out, that doesn't make any sense, that list of URLs should depend solely on the title.

Also, why is autoCreateUser() triggered before setup is complete?

Part of setup is determining the User making the request. If that User doesn't exist locally yet, it has to be auto-created to have it available to finish the setup.

Could that be deferred until the point where the User object would usually be initialized from the session?

In T240083#5732516, @daniel wrote:

Could that be deferred until the point where the User object would usually be initialized from the session?

That seems like it would bring back the problems from T43201: UserLoadFromSession considered evil. We specifically wanted auto-creation to happen at a predictable place during setup rather that it happening unexpectedly at any time during the request.

Change 580482 had a related patch set uploaded (by Anomie; owner: Anomie):
[mediawiki/core@master] CdnCacheUpdate: Accept Titles in addition to strings

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

Change 580482 merged by jenkins-bot:
[mediawiki/core@master] CdnCacheUpdate: Accept Titles in addition to strings

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

Note the the solution that was just merged is quite far from what is discussed in the task description. If further work is desired here, please re-open.