PS should drop handles causing InspectHandles failing

[chihyu]

Tested with three different machines: build 653, joyride 1454 (clean install), joyride 1454 (olpc-updated from build 653).

All machines were connected to mesh network 1 (school server).

Go to Neighborhood view, hover mouse over buddy icons -- some buddy does not have a name, but can possibly be added as a friend or invited to an activity.

[marco]

Probably a presence service bug. Seems like it would be worth to spend some time to at least track down the issue for Update.1.

[jg]

Whether we can fix it will of course, depend on the fix...

[morgs]

chihyu, any chance of logs? http://wiki.laptop.org/go/AttachingSugarLogsToTickets

I can't reproduce this myself and need the presenceservice.log of a laptop while it is seeing a buddy with no name.

[chihyu]

I am attaching three possible presenceservice.log files during the time period I created this ticket. Thanks a lot!

Replying to morgs:

chihyu, any chance of logs? http://wiki.laptop.org/go/AttachingSugarLogsToTickets I can't reproduce this myself and need the presenceservice.log of a laptop while it is seeing a buddy with no name.

[chihyu]

presenceservice.log (Dec. 20)

[chihyu]

presenceservice.log (Dec. 21) 1 of 2

[chihyu]

presenceservice.log (Dec. 21) 2 of 2

[morgs]

In the logs, attempts to get aliases, buddy properties, current activity and activities for a handle.

It looks like the handle disappeared by the time we want to get these, in fact probably before we create a Buddy object and connect to the disappeared signal.

[marco]

<morgs> marcopg: #5618 seems to be when a buddy appears and disappears before we can create the buddy object and hook the disappeared signal, so we have a phantom buddy which has no telepathy handle.
<morgs> I haven't heard of it happening outside 1cc.
<marcopg> morgs: I tend to think it's not critical for Update.1 then and should be punted
<morgs> marcopg: I agree, changes would be too invasive to fix a really small issue

[marco]

If we can't do anything without more info let's close this one.

[mstone]

Dear Collabora - we need to know whether this is still a problem. Could you please comment?

[gdesmott]

According logs, I observed the following failures:

InspectHandles failed in telepathy_plugin.py:_contacts_online

Error when fetching alias, buddy properties, activities, current activity in presenceservice.py: _contacts_online

BuddyInfo.GetProperties failed in linklocal_plugin.py: identify_contacts

As the first failure is in telepathy_plugin.py:_contacts_online, we could probably drop the handle if InspectHandles fails. Problem is, I don't think we can identify which handle cause the failing if more than one handle is passed to InspectHandles.

[gdesmott]

According smcv, the futur Inspectotron should solve this problem.

[gdesmott]

After further discussions we agreed to write a fallback path instead of waiting for the futur API. Will fix it.

[mstone]

The detailed problem is that the PS uses a batch query API (InspectHandles) that has no way to indicate that individual sub-queries failed. Inspectotron is a newer batch-query API that does not suffer from this problem; however, it is not scheduled for use in 8.2.0. In the mean-time, Sjoerd suggests a simple PS workaround: requery results one at a time when the overall batch query fails.

[gdesmott]

I have a fix in my "5618" branch: https://dev.laptop.org/git?p=users/guillaume/presence-service;a=shortlog;h=5618

[gdesmott]

Merged to master, thanks to Morgs and Sjoerd for the review.

If you want this fix in 8.2.0 I can merge it to the stable branch (sucrose-0.82) too and do a 0.82.1 stable release.

[mstone]

When you have tested that the patch fixes the issue, please see that this makes its way into joyride.

[gdesmott]

Merged to the sucrose-0.82 stable branch.

[gdesmott]

I released and packaged PS 0.82.1 which contains this fix. Package has to be tagged to reach Joyride.

[gdesmott]

sugar-presence-service 0.82.2 is now in Joyride so this bug should be fixed. Will do some tests in build to be sure it didn't introduced regression but the bug is very rare and hard to reproduce.

[gdesmott]

Did some tests and things seemed to work fine.

[mstone]

Please tag the ticket with your test results according to http://wiki.laptop.org/go/Trac_conventions

[daf]

Ignoring InspectHandles errors doesn't seem like it addresses the root problem: the problem is that the presence service has invalid handles. Either the connection manager is not telling the presence service when a handle is invalidated, or it is generating that information and the presence service is not paying attention to it.

It's hard to tackle this without being able to reproduce it, though.

[gdesmott]

A possible scenario could be:

- Buddy is online. PresenceChanged(online) is fire from the CM
- Right after, buddy becomes offline, PresenceChanged(offline) is fired
- PS is scheduled and catch the first signal: the handle is not valid anymore

Move this bug to 9.1 as we workarounded it for 8.2 and we can't really debug it without a test framework.