I can't reproduce this locally.

Do any of the details I provided in T8504 (like the mention of the gray circle) help you understand what's going on here?

Maybe. Do you have approval queues on, or email verification on?

auth.require-approval is false
auth.require-email-verification is false

D13239 will fix this in some cases.

The grey dot indicates that the account is not activated. There are three conditions which make accounts "not activated":

• Account is disabled.
• Account is not approved.
• Email address is not verified (and verification is required).

I can't immediately identify a way for an account to be "not activated" with those options off.

D13239 may reveal whatever the root issue is.

Can you show me the result of this?

mysql> SELECT isDisabled, isEmailVerified, isApproved FROM phabricator_user.user WHERE username = 'username';

+------------+-----------------+------------+
| isDisabled | isEmailVerified | isApproved |
+------------+-----------------+------------+
|          0 |               0 |          1 |
+------------+-----------------+------------+

Some more useful data:

• Last week (before we upgraded Phabricator), I needed to create a user for something. I created a user from /people/, used ./bin/auth recover to log in as that user, and then the web UI immediately presented me with a "you must verify your email to use the website" screen.
• Today, I just went through the same steps -- and instead of seeing "you must verify your email," I see the "login failure" page.
• I checked our database to find a full list of all users with isEmailVerified=0. It's a bunch of really old test accounts, and then new accounts created this week. Every other account on our install is email verified.
• I double-checked our settings. auth.reuqire-email-verification displays as "false" in the list of all config settings, but when I click into it, it says "Value (Use Default)" and then further clarifies "By default, verification is optional unless auth.email-domains is nonempty." Our auth.email-domains setting is non-empty, so I think we do require email verification.

So, it very likely is the email verification requirement that's causing this problem. Will D13239 fix the issue in this case?

Oh, is auth.email-domains set?

Yes, it is.

Sorry, bad at reading. Yeah, that's the issue. D13239 will fix things.

You can likely work around it in the meantime by setting isEmailVerified to 1 in that table. (I expect D13239 will land in the next few hours.)