Found a bug in 2.1.0.beta2 (derived from page source) from which may be an edge or corner case but nevertheless it should be reproducible. It impacts the user sign-up flow for individuals who bail on SSO in favor of an email sign-up. The impact is that an available username becomes reserved by the system. Here’s a visual of the bug, which is preventing me from signing up for community.bitwarden.com with my preferred username: [55%20PM] Impacted users: Users who decide not to use SSO and bail on the process. To reproduce: Navigate to community.bitwarden.com (or preferably a test server running 2.1.0.beta2). Attempt to sign-up for an account using SSO with GitHub. Do not complete registration by email. Attempt to sign-up again by email. Observe email not received. Refresh with cache clear. Attempt to sign-up again by email. Observe username unavailable. I’m not aware of model state is at this point in the back-end but I’m guessing there’s a username in a users table without an associated email address or with an incorrect email address, and possibly erroneously linked to a GitHub account. Only way I can see to get my username back is to contact the forum admins or wait and hope there’s some kind of reclaimation process to purge users who didn’t complete the sign-up in full.

[image] itsbhanusharma: I can probably confirm what happens! … After the period you’ve stated in : purge_unactivated_users_grace_period_days the username should become available again. Yes, this is as designed, and the above is true. The default for that setting is 14 days though. Your workaround is simply to complete the login via GitHub.

Isn’t that kind of an edge case? why would someone signing up from github all of a sudden change their mind and start the sign up process all over again? I’m quite sure that there should be threshold after which the username will be available again (in case your system has created an account which isn’t activated yet) but this isn’t a case that is gonna happen on a regular basis! and 11 Steps to reproduce? Would like to add to this, This can potentially be by design too as just in case the Github user changes his mind and wants to sign up again then they would be upset that their username (which was available) has all of a sudden gone unavailable. There can be network issues too in case a user was authorizing and their network went down?>

[image] itsbhanusharma: Isn’t that kind of an edge case? As stated above, this is probably an edge case. [image] itsbhanusharma: and 11 Steps to reproduce? Log-in flows are complex by nature. It could be reduced with loss of detail. [image] itsbhanusharma: I’m quite sure that there should be threshold after which the username will be available again That’s in part why I opened this bug. It’s not clear that will actually happen.

[image] balibebas: It’s not clear that will actually happen. I can probably confirm what happens! … After the period you’ve stated in : purge_unactivated_users_grace_period_days the username should become available again. [image] balibebas: Log-in flows are complex by nature. It could be reduced with loss of detail. I still don’t understand how much rare it would be for someone to all of a sudden ditch social sign in and start the registration flow again.

[image] itsbhanusharma: I still don’t understand how much rare it would be for someone to all of a sudden ditch social sign in and start the registration flow again. I’m not sure myself either. In my case I simply didn’t have access to my GitHub email address to confirm login and choose to use an email I did have access to. [image] itsbhanusharma: I can probably confirm what happens! Thanks for making me aware of this. Not sure what the default setting is or if the admins of the forum have customized it but I’ll just wait and try to sign-up again once purged. Note on the above, I’ve reduced the number of steps to reproduce from 11 to 8.

[image] balibebas: didn’t have access to my GitHub email address to confirm login and choose to use an email I did have access to. If your address is verified on github then you shouldn’t be receiving a confirmation email from discourse. And I’d stress again this all more or less looks like it is by design not by fault so I think this belongs to support not bug.

[image] balibebas: Not sure what the default setting is config/site_settings.yml main show_badges_in_post_header: client: true

Given the purge process is in place I’d say this issue isn’t worth anymore attention. Thanks to @itsbhanusharma and @Mittineague for your help leveling up my understanding. And to satisfy any curiosity I typically choose not to use SSO in favor of password management in most cases and have found a way to quiet GH email notifications on my account: [35%20PM]

Username Not Available when signing up twice, first incompletely

Product Support

Mittineague (Mittineague) June 22, 2018, 5:33am 7

Topic		Replies	Views
Regression: new check_username rate limit can block normal signup flow Bug signup	4	271	September 17, 2026
Blank page upon GitHub sign in, unable to sign in Product Support	4	1241	November 8, 2016
User who mistakenly used reserved username can't join via invite Bug	1	705	May 22, 2023
New users unable to sign up Product Support	3	769	October 5, 2021
Easier account signup using email codes Announcements login , signup	50	2716	October 21, 2026

Username Not Available when signing up twice, first incompletely

Related topics