Having looked into this a bit more, GlobalBlocking is causing a valid problem to be surfaced where the user Nr: 135 does exist in all of the enwiki.user, centralauth.globaluser, and centralauth.localuser.

Therefore, this is an issue with MediaWiki-extensions-CentralAuth

Because our team does not own MediaWiki-extensions-CentralAuth, we do not have the decision making authority to decide what to do with the user "Nr: 135". It is likely that they will have to be renamed to fix the user, but I (or my team) cannot make that decision.

Therefore, I am removing the Product Safety and Integrity team tag and have updated the task to focus on fixing the specific invalid user. The checks in GlobalBlocking are correct because they check first if a local user ID exists for the username, which should prevent any issues surrounding fetching the central ID of a invalid username

See: T372880: User::isAllowed throws from CentralAuthUser when username contains colon, T377588: CentralAuthIdLookup throws from CentralAuthUser for username with a colon

Also seen for "H:harihar" on enwikisource: https://logstash.wikimedia.org/app/dashboards#/doc/logstash-*/logstash-deploy-1-7.0.0-1-2025.12.16?id=5xy8J5sBFM-LSVmL5vl2

There are two ways this can happen.

1. One way is to create the account on a wiki where the username is valid, and then try login (auto-create) on a wiki where that name is invalid due to a local namespace name or namespace alias. For example WP: a local alias for Wikipedia: on various wikis, but would not be reserved as such on Meta-Wiki or Commons.

Impact: This prevents login and autocreate, forcing the user to stay logged-out, but keeps integrity of local user account validity and does not pose issues with viewing contributions or assigning user rights, because the account never starts to exist, and thus doesn't need to be interacted with. This is similar to what happens with local AbuseFilter today (T354487), although that one is fixable by issueing a create+block instead of denying creation. We probalby can't do that with cases where the name is invalid rather than disallowed.

2. Another way is to introduce a namespace alias or interwiki after such an account already exists. This could be a local namespace, or a global interwiki prefix. For example, an account may have been created in the past before the WP: alias was locally requested on that same wiki. Or in the case of an interwiki or interlanguage prefix, if the account predates the creation of a wiki in that language.

Impact: This means an account retroactively becomes invalid and creates problems with Special:Contributions and other UIs/APIs. This task is an example of this. The Nr: 135 account predates the creation of https://nr.wikipedia.org and the nr: interwiki prefix. We have the WikimediaMaintenance/renameInvalidUsernames.php script for this exact purpose. It looks like this hasn't been part of the Add a wiki process in practice.

In discussing this with the MediaWiki Platform Team today, @Tgr mentions that long-term we should disallow creation of accounts with : so that this issue doesn't happen again. We actually already did that in 2015 (T98757), with the introduction of wgInvalidUsernameCharacters which is used to deny use of : in new usernames. However, as @matmarex already noted in August 2024 at T372880#10093187, we have yet to do a mass rename (T160296).

We resolved T372880 for User::isAllowed by avoiding CentralAuthUser. The trace in the current task looks almost the same, but comes instead from CentralAuthIdLookup (via User::getBlock/extensions-GlobalBlocking). This is already reported and tracked at T377588.

In T401212#11461372, @Dreamy_Jazz wrote:

Because our team does not own MediaWiki-extensions-CentralAuth, we do not have the decision making authority to decide what to do with the user "Nr: 135". It is likely that they will have to be renamed to fix the user, but I (or my team) cannot make that decision.

Our decision is that such usernames are invalid and should be renamed. Please work with the stewards and this user to rename the account.

The medium-term task for MediaWiki Platform Team to supporting this in CentralAuth is T377588: CentralAuthIdLookup throws from CentralAuthUser for username with a colon.

The long-term task for renaming other accounts is T160296: Rename global users with invalid characters on their usernames.

I'm not sure Product Safety and Integrity has the bandwidth to be renaming specific accounts when we see them, given that we need to go and ask stewards to do this each time we see these accounts (instead of being able to do it ourselves).

Given the above, I would say that it is better to do this through T160296: Rename global users with invalid characters on their usernames because this issue would appear for any of the accounts that have invalid usernames and doing this in one batch would be better (especially for the stewards as a mass rename is quicker than one-by-one)