We have moved users to a database connection and were unable to create a user via email on the database connection (source) due to a 409 Conflict error, stating the user already exists. In addition, the user does not get returned when using getByEmail API or the list users API with q parameter.
- Customer cannot create a new user with a certain email address(es) - but gets a 409 error “user already exists”
- New email address does not show in searches
- Customer is using a Custom DB connection in import mode
A possible route to users ending up in a half-created state is by them initiating a password reset flow on a Custom DB they haven’t logged in on before with an email that is valid on the legacy DB, but not completing the flow. This creates a user in one of the Auth0 database collections, but not the one that can be polled by user search.
This is typically observed with Custom Databases, with import mode either on or off. There are two things to check:
- Is the “Get user” script in the Custom DB returning a profile?
Auth0 executes the “Get User” script before creating the user, to make sure the user doesn’t exist in the external (custom DB). If the script returns a profile (instead of returning
null) Auth0 interprets that as “This user already exists” and prevents the creation.
This can be tested by hitting the “Test” button when looking at the Get User script for the custom database.
- User changed their password but never logged in. This is more of a corner case that can happen if:
- The user did a complete password reset flow (“Forgot your password?”), but did not log in after that.
- You are using a Custom DB with Import Mode On. When this happens, Auth0 remembers the new password in a record that cannot be found when searching for the user (there’s no full user profile imported to Auth0 yet), but it prevents the user from being created again (because it would result in a different password than the one the user chose). There are two ways to recover from this situation:
- Have the user login (with the password they set). If they don’t remember the password, they can do the password reset flow again.
- Use the Delete user by email endpoint to delete that ghost user from the Auth0 side. Note that if the user was able to do the password reset flow to get to this state, this means that the user already existed in the external database. By doing this deletion you are essentially deleting the new password, so the user will need to use the previous password (in the external DB) to log in.