The stack trace in the task description is a parse (from the extracts API). So there are three options:

• CentralAuthUser::loadState() is slow (some kind of lock contention?)
• Parsing is slow, because it makes many CentralAuthUser::loadState() calls (they are from the TitleIsAlwaysKnown hook in GlobalUserPage which is trying to determine whether the user page link should be red or blue).
• Parsing is slow for some unrelated reason (maybe the page is just huge) and CentralAuthUser::loadState() just happens to be where it hits the time limit. Not very likely if it shows up regularly in the stack traces.

Probably it's the second. The log event linked from the description is for https://en.wikipedia.org/wiki/Wikipedia:Arbitration_Committee_Elections_December_2019/Coordination/SP/human?action=raw (parsing times out on the web UI as well) which has about 40K user page links, so not very surprising that it times out.

Unhelpfully, the parser checks Title::isAlwaysKnown() before Title::exists() even though the latter is batched and way way cheaper.

I don't think there is anything in CentralAuth that can be done here. Either the parser should support batch lookup / warming of isAlwaysKnown() (there is already a comment to that effect in the code) or there should be some way to increment the expensive counter from a TitleIsAlwaysKnown hook handler. Or at least the order of operations should be flipped and isAlwaysKnown() only called for non-existent titles, although that wouldn't help on a page with lots of links to non-existent user pages.

How high priority is this? Can it wait until the Parsoid roll out (June 2026)? We'd like to fix this only on the Parsoid side if possible, rather than having to do multiple fixes.

Is there already a batch API that can be used for the media namespace, or is part of this task building a batch API for ::isAlwaysKnown queries?

I think we'd need to build a batch version of the TitleIsAlwaysKnown hook (or something more generic, like a WarmTitleCache hook).

This is an issue with the media namespace as well (where the color of a link to a file description page can depend on whether the file exists on another wiki), but the error in this task is about user namespace links. And in theory it could be anything, depending on what extensions implement TitleIsAlwaysKnown and how.

This has nothing to do with CheckUser-SuggestedInvestigations from what I can see. Removing that tag.

The root cause seems to be the calls to CentralAuthIdLookup::isAttached which loads the entire CentralAuthUser object for each user that is checked. For example, a request that I ran using the excimer profile includes 11 seconds of just loading user groups. These are not even used as part of the ::isAttached check.

To fix this, a method needs to be added that allows batching the evaluation of ::shouldDisplayGlobalPage that uses the batch TitleIsAlwaysKnown hook proposed above. Then that code would use CentralIdLookup::lookupAttachedUserNames for the batch lookup

There is no way loading user groups can take 11 seconds, without some sort of deadlock. It's a straightforward SELECT using the primary key, returning a few dozen rows at most.

In T408666#11444016, @Tgr wrote:

There is no way loading user groups can take 11 seconds, without some sort of deadlock. It's a straightforward SELECT using the primary key, returning a few dozen rows at most.

This is because the SELECT query is duplicated hundreds of times, because the loading is not batched and one user-by-user. Therefore, while the queries themselves may not take 11s seconds in total with all the overhead it likely does.