Speculation: A race between the CentralAuthCreateLocalAccountJob for loginwiki and the redirect to Special:CentralAuth/start, so the latter somehow sees the local user created but the central user not (or at least not attached).

So we'd either need to make SpecialCentralAuth figure out that the user is just in the process of being attached and be more silent (by checking whether the account creation date was within 10s, maybe?), or write lock either the local or the global user record in AuthManager::autoCreateUser so that SpecialCentralAuth is blocked until the attachment finishes.

The second seems more theoretically correct, the first seems way less disruptive though.

Change 318477 had a related patch set uploaded (by Gergő Tisza):
Do not spam logs when the loginwiki user is unattached due to a race

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

Change 318649 had a related patch set uploaded (by Gergő Tisza):
Retry failed centrallogin checks from master

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

Change 318649 merged by jenkins-bot:
Retry failed centrallogin checks from master

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

Change 318477 abandoned by Gergő Tisza:
Do not spam logs when the loginwiki user is unattached due to a race

Reason:
You were right, no errors over the last week.

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