buddy-related signals processed before buddy list is received

[carrott]

os871 and os872 (11.2.0 I think) on XO 1.0

We see this exception in shell.log on a regular basis on all our XO-1.0s.

310169861.125557 ERROR dbus.connection: Exception in handler for D-Bus signal:
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/dbus/connection.py", line 214, in maybe_handle_message
    self._handler(*args, **kwargs)
  File "/usr/lib/python2.7/site-packages/jarabe/model/neighborhood.py", line 430, in __buddy_info_updated_cb
    self.emit('buddy-updated', self._buddy_handles[handle], properties)
KeyError: dbus.UInt32(4L)

[dsd]

I can reproduce this too, on connecting to jabber.sugarlabs.org

OLPC OS 11.2.0 build 871, sugar 0.92.2

There is a problem in model/neighborhood.py class Account method __get_self_handle_cb

This method connects a load of signals (such as __buddy_info_updated_cb which is getting called here) and then afterwards (via channel.Get(Members)) requests a list of all connected buddys at which point it adds them to its internal model.

What is happening here is that some signals are being received before the list of connected buddys has been downloaded and processed.

I was going to suggest that this be fixed by only connecting signals after the the buddy list has been received. That would be upon completion of __get_contact_attributes_cb. However, I think this would be racy as well: what if a buddy disconnects immediately after the members list has been received, but before the signals have been connected?

So I think the correct approach here is to harden up all of the signal handlers so that they can happily do nothing if the buddy they are trying to process is not (yet) known by the model. I see that some of them already do this to an extent, via if handle in self._buddy_handles checks.

[ajay_garg]

Patch at ::

 http://patchwork.sugarlabs.org/patch/1133/

[ajay_garg]

Attaching the patch, after changing patch description (courtesy Sascha).