IntegrityError: duplicate key value violates unique constraint "emailaddress__person__key"

Bug #862944 reported by Selene ToyKeeper
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Canonical SSO provider
Fix Released
Critical
Simon Davy

Bug Description

I received a ticket that a user cannot log into any of our services because they get an OOPS every time. I checked the logs (OOPS 2092canistelubuntu1424), and it seems that their account has managed to violate a database constraint somehow. The traceback includes:

  File "/usr/lib/pymodules/python2.6/django/contrib/auth/__init__.py", line 55, in authenticate
    user = backend.authenticate(**credentials)
  File "/srv/login.ubuntu.com/production/canonical-identity-provider/identityprovider/auth.py", line 59, in authenticate
    account.last_login = datetime.now()
  File "/srv/login.ubuntu.com/production/canonical-identity-provider/identityprovider/models/account.py", line 201, in _set_last_login
    if self.user is not None:
  File "/srv/login.ubuntu.com/production/canonical-identity-provider/identityprovider/models/account.py", line 183, in user
    if self.preferredemail:
  File "/srv/login.ubuntu.com/production/canonical-identity-provider/identityprovider/models/account.py", line 142, in _get_preferredemail
    email.save()
...
IntegrityError: duplicate key value violates unique constraint "emailaddress__person__key"

Tags: sp-1 kb-defect
Changed in canonical-identity-provider:
importance: Undecided → Critical
status: New → Triaged
Revision history for this message
Selene ToyKeeper (toykeeper) wrote :

... why does a login procedure end up calling a line like 'email.save()' ? That seems rather odd.

I guess it could be used to automatically mark which address is preferred, but that seems like a task better done in the session than in long-term storage.

Revision history for this message
Łukasz Czyżykowski (lukasz-czyzykowski) wrote :

It's part of long term storage because SSO needs to know which address to use when sending out emails.

Revision history for this message
Selene ToyKeeper (toykeeper) wrote :

The user can manually set which address is preferred... I'd rather set that once, manually, than have it change each time I log in (if I log in with a non-preferred address).

That's kind of tangential though. Not writing changes on login could maybe bypass the problem, but wouldn't actually fix the root cause.

Revision history for this message
Łukasz Czyżykowski (lukasz-czyzykowski) wrote :

The preferred address doesn't change if you log in using non-preferred one.

It's set only in case when there's no preferred email. In normally this is set by the user, via the web interface, and the login process doesn't need to touch it. Only in case when there's no such address (which is an exception, not the norm) the db is modified.

Changed in canonical-identity-provider:
assignee: nobody → Simon Davy (bloodearnest)
Revision history for this message
Simon Davy (bloodearnest) wrote :

This is caused by the fact that there *is* a preferred email for this user, but it is linked to their lp_person and not to this account.

Fix is to check lp_person as well as account for preferred emails

Revision history for this message
Selene ToyKeeper (toykeeper) wrote :

Neat, sounds like it should be relatively easy to fix and will close a few tickets for me. :)

Changed in canonical-identity-provider:
status: Triaged → In Progress
Changed in canonical-identity-provider:
status: In Progress → Fix Committed
tags: added: kb-task sp-1
tags: added: kb-defect
removed: kb-task
Revision history for this message
Simon Davy (bloodearnest) wrote :

The fix committed fixed the reported case, but the same error was raised again with a more complex root cause: see 52679-2174canistelubuntu1983.oops

The new fix is more generic and *should* prevent this error from preventing login

Changed in canonical-identity-provider:
milestone: none → 12.01.05
Changed in canonical-identity-provider:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Related questions

Remote bug watches

Bug watches keep track of this bug in other bug trackers.