This is a centraluser caching issue; upon registration, a job creates the local user at mw.org, but enwiki does not see it due to a stale cache:

tgr@terbium:~$ mwscript eval.php --wiki=enwiki
> $u=User::newFromName('Test-T105105-1');
> $cu=CentralAuthUser::getInstance($u);
> var_dump($cu->attachedOn('mediawikiwiki'));
bool(false)
> $cu->invalidateCache();
> var_dump($cu->attachedOn('mediawikiwiki'));
bool(true)

https://gerrit.wikimedia.org/r/#/c/223211/ should have fixed that but apparently it does not always work.

@aaron, could this be caused by CentralAuth not using WANObjectCache? Multi-datacenter caching is not actually enabled yet, is it? (And I guess if that were the case, running invalidateCache by hand would not help either.)

@Legoktm can we just drop attachment tests (make them always return true)? At this point, it shouldn't be possible for a local account to exist and be unattached, right?

In T105105#1436729, @Tgr wrote:

At this point, it shouldn't be possible for a local account to exist and be unattached, right?

Turns out there are still a few.

Legoktm suggested this might be a race condition due to master-slave delay; the cache is written from a slave after the job invalidates it but before the slave has caught up.

Change 225011 had a related patch set uploaded (by Gergő Tisza):
Fix CreateLocalAccountJob caching

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

In T105105#1456385, @Tgr wrote:

Legoktm suggested this might be a race condition due to master-slave delay; the cache is written from a slave after the job invalidates it but before the slave has caught up.

Maybe I misspoke, CentralAuthUser::loadState() always reads from the master if the cache has been invalidated...

You are right. I was looking at CentralAuthUser::newFromId() but actually it does not use the slave DB for anything important (and it doesn't seem to be used outside the rename stuff anyway). Back to having no clue then...

Change 225011 abandoned by Gergő Tisza:
Fix CreateLocalAccountJob caching

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

Using the master does not deal with latency or snapshot induced cache update race conditions. https://gerrit.wikimedia.org/r/#/c/225013/ will help with that in passing (assuming reasonable time bounds of the threads in question).

As an interim solution, it would be great to get an improved error message that directs the user to try logging out and back in if they get error 008 immediately after creating their account.

Can you recommend any exact text? The message is mwoauthserver-invalid-user.

Here's my recommended text:

There was a problem with logging you in globally. If you just created your account, please log out and log back in, then try again to authorize the app. If you did not just create your account, please visit another Wikimedia site while logged in — such as mediawiki.org — and then try again to authorize the app.

That should help the vast majority of users who hit the 008 error.

Can't reproduct anymore, looks like Aaron's patch fixed it. Improving the error message is a good idea regardless.

Change 230276 had a related patch set uploaded (by Gergő Tisza):
Wikimedia-specific error message for OAuth error E008

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

Change 230276 merged by jenkins-bot:
Wikimedia-specific error message for OAuth error E008

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

I have a user who can reproduce this issue still on IRC when trying to report another issue in Phab. In his case, the error message of "please visit another Wikimedia site while logged in — such as [https://mediawiki.org/ mediawiki.org] — and then try again to authorize the app." doesn't make much sense since he is on mw.org :)

...and visiting en.wikipedia.org then trying to login to Phab again didn't fix the issue for him.

Have him visit meta, maybe, since that's the new centralauth place?

I would have him subscribe/respond to this task, buuuuuuuut.....

Sorry, didn't see your comment before I sent my last one, @Ragesoss (hi, btw!)

That worked!

I guess we need to update that error message, at least....

@greg can you describe the exact steps they took, also when the account was registered and whether the user visited other wikis before?

It doesn't really matter which site they visit as long as it is a different one (and not just a different language version of the same family), it will create an account everywhere. (Which is arguably a bug: T18864. So yeah, recommending to visit the central wiki is probably more future-proof.)

Simonft registered on enwiki before account autocreation was enabled and did not visit other wikis until now. So this is T74469. We cannot autocreate accounts for all existing users - the meta community probably wouldn't welcome a million new accounts being created. So we should ensure that autocreation can happen at the last moment, when the user visits the authorization dialog. That's hard with the current code but it will have to be rewritten anyway due to AuthManager (T110291). We'll see if it's easier to fix after that.

Thanks @Tgr for the explanation!

In T105105#1673278, @Tgr wrote:

Simonft registered on enwiki before account autocreation was enabled and did not visit other wikis until now. So this is T74469.

Actually I had a separate non-closed task for that: T94885