If a user hits refresh during a long database stall and kicks off a second user-create (on first login with an idp), two users associated with the same idp could be created (i.e., both instances will check to see if that idp exists, and if a user with that idp exists; both will create a user with that idp; and then both transactions will commit). I can reduce the window in which that intermediate state exists (having both check later to see if someone else has come in), but I do not have the expertise to make that disallowed state not exist at all.
In the mean time, I'm solving this just by cleaning this up by hand...
If a user hits refresh during a long database stall and kicks off a second user-create (on first login with an idp), two users associated with the same idp could be created (i.e., both instances will check to see if that idp exists, and if a user with that idp exists; both will create a user with that idp; and then both transactions will commit). I can reduce the window in which that intermediate state exists (having both check later to see if someone else has come in), but I do not have the expertise to make that disallowed state not exist at all.
In the mean time, I'm solving this just by cleaning this up by hand...