AssertionError from logins #128
Description
It seems many users experience a HTTP 500 error the first time they log in using the federated authentication.
It is caused by an AssertionError triggered by attempting to insert their email. It happens when trix/trix_auth /allauth_adapter.py's save_user function uses allauth/socialaccount/models.py's save function which uses allauth/account/utils.py's setup_user_email. Trace:
allauth/account/utils.pyinsetup_user_emailat line 266allauth/socialaccount/models.pyinsaveat line 253trix/trix_auth/allauth_adapter.pyinsave_userat line 25allauth/socialaccount/helpers.pyin_process_signupat line 47allauth/socialaccount/helpers.pyin_complete_social_loginat line 181allauth/socialaccount/helpers.pyincomplete_social_loginat line 160allauth/socialaccount/providers/oauth2/views.pyindispatchat line 158allauth/socialaccount/providers/oauth2/views.pyinviewat line 81django/core/handlers/base.pyin_get_responseat line 181django/core/handlers/exception.pyininnerat line 47
Line 266 in allauth/account/utils.py reads:
assert not EmailAddress.objects.filter(user=user).exists()
When it yields an exception, the values it receives (among other things) an user object (<User: username@uio.no>) and an addresses object ([ <EmailAddress: username@uio.no>]) where username in both cases is a valid UiO username.
It looks to me that AssertionError is triggered due to some failed check: SELECT (1) AS "a" FROM "account_emailaddress" WHERE "account_emailaddress"."user_id" = %s LIMIT 1.
For some reason this doesn't happen in our test environment so unclear if we have some unintended differences between test and production, or if its simply «a numbers game».