send-person-notifications.py is broken

Bug #514149 reported by Steve McInerney
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Launchpad itself
Fix Released
High
Curtis Hovey

Bug Description

Traceback (most recent call last):
  File "/srv/launchpad.net/production/launchpad/cronscripts/send-person-notifications.py", line 77, in <module>
    script.lock_and_run()
  File "/srv/launchpad.net/production/launchpad-rev-8939/lib/lp/services/scripts/base.py", line 290, in lock_and_run
    implicit_begin=implicit_begin, isolation=isolation)
  File "/srv/launchpad.net/production/launchpad-rev-8939/lib/lp/services/scripts/base.py", line 248, in run
    self.main()
  File "/srv/launchpad.net/production/launchpad/cronscripts/send-person-notifications.py", line 48, in main
    % (person.name, person.preferredemail.email))
AttributeError: 'NoneType' object has no attribute 'email'

Related branches

Revision history for this message
Diogo Matsubara (matsubara) wrote :

Curtis, see also bug 514233

affects: launchpad → launchpad-registry
Changed in launchpad-registry:
status: New → Triaged
importance: Undecided → High
Revision history for this message
Curtis Hovey (sinzui) wrote :

The error looks like an Account and Email sync issue between master and slave. These issues solve themselves when the db fixes itself.

Given that bug 514233 says the only use case for this script was removed in September, How can we an entry in this table?

Changed in launchpad-registry:
status: Triaged → Incomplete
importance: High → Low
importance: Low → Undecided
Revision history for this message
Curtis Hovey (sinzui) wrote :

~info-orod-deactivatedaccount is a merged, yet deactivated account. The account looks like it was create and deactivated/merge before the email address information could be replicated from master to slave db. We can fix this instance by deleting the row with for this user.

Changed in launchpad-registry:
status: Incomplete → In Progress
importance: Undecided → High
milestone: none → 10.02
assignee: nobody → Curtis Hovey (sinzui)
Revision history for this message
Curtis Hovey (sinzui) wrote :

Deleting the insane user fixed the script. This bug is closed, but we need to look at releated None-user issues to see if replication errors caused this.

Changed in launchpad-registry:
status: In Progress → Fix Released
Curtis Hovey (sinzui)
tags: added: qa-ok
Revision history for this message
Stuart Bishop (stub) wrote :

This bug has not been fixed and is still being triggered

The situation described is normal and needs to be coped with - we can't assume that if a user has a preferred email address in one transaction it will still have one in the next transaction for reasons that have nothing to do with replication.

Changed in launchpad-registry:
status: Fix Released → Triaged
Revision history for this message
Curtis Hovey (sinzui) wrote :

Then what is the correct fix? Prevent the notification from being inserted into the table, or to modify the script to remove the entry. I think the later is more robust.

Curtis Hovey (sinzui)
tags: added: oops
removed: qa-ok
Curtis Hovey (sinzui)
Changed in launchpad-registry:
status: Triaged → In Progress
Curtis Hovey (sinzui)
Changed in launchpad-registry:
status: In Progress → Fix Committed
Curtis Hovey (sinzui)
tags: added: qa-needstesting
Curtis Hovey (sinzui)
tags: added: qa-ok
removed: qa-needstesting
Revision history for this message
Curtis Hovey (sinzui) wrote : Bug 514149 Fix released

Fixed released in launchpad-project 10.02.

Changed in launchpad-registry:
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

Remote bug watches

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