Bug 38712

Summary:	uninvite does not work
Product:	Telepathy	Reporter:	Simon Schampijer <simon>
Component:	salut	Assignee:	Telepathy bugs list <telepathy-bugs>
Status:	RESOLVED MOVED	QA Contact:	Telepathy bugs list <telepathy-bugs>
Severity:	major
Priority:	medium
Version:	0.4
Hardware:	Other
OS:	All
Whiteboard:
i915 platform:		i915 features:
Attachments:	tp-salut logs from machine A tp-salut logs from machine B

Description Simon Schampijer 2011-06-27 05:38:18 UTC

- open an activity on machine A

- invite machine B to it

- quit activity in machine A

---> a new invitation on machine B is launched, a chat activity in the color of machine B and the invitation is not removed 

I would expect that the previous invitation is removed on B as A did close the activity.

Comment 1 Simon Schampijer 2011-06-27 05:41:15 UTC

Created attachment 48466 [details]
tp-salut logs from machine A

Comment 2 Simon Schampijer 2011-06-27 05:41:45 UTC

Created attachment 48467 [details]
tp-salut logs from machine B

Comment 3 Guillaume Desmottes 2011-06-27 06:53:22 UTC

In B's log:

** (telepathy-salut:2224): DEBUG: uninvite_stanza_callback: room ca6e5f59@laptop unknown


So it gets the uninvite stanza but for some reason the handle has been lost somewhere. The SalutOlpcActivity is supposed to keep the ref on the handle. Can you add some debug in olpc-activity.c to check if the object created when receiving the invitation stays alive?

Comment 4 Simon Schampijer 2011-06-27 09:00:47 UTC

(In reply to comment #3)
> In B's log:
> 
> ** (telepathy-salut:2224): DEBUG: uninvite_stanza_callback: room
> ca6e5f59@laptop unknown
> 
> 
> So it gets the uninvite stanza but for some reason the handle has been lost
> somewhere. The SalutOlpcActivity is supposed to keep the ref on the handle. Can
> you add some debug in olpc-activity.c to check if the object created when
> receiving the invitation stays alive?

What I tried is to set the room_handle there to '1' and this does then finally remove the invitation activity. So, the room is still there and either the list of handles is not right anymore or what we get from the stanza 'gibber_xmpp_node_get_attribute (node, "room");' is faulty.

Comment 5 Guillaume Desmottes 2011-06-28 07:16:27 UTC

You can use tp_handle_set_dump() to dump all the known handles.

Comment 6 Simon Schampijer 2011-06-30 02:40:34 UTC

(In reply to comment #5)
> You can use tp_handle_set_dump() to dump all the known handles.

In telepathy-glib-0.11.16-1 which we use on this fc14 based build we do not seem to have tp_handle_set_dump if my greps are correct. Anything else I can use to quickly find out?

Comment 7 Guillaume Desmottes 2011-06-30 03:07:48 UTC

Outch that's very old. You should really consider upgrading to tp-glib 0.14.x (stable branch).

Comment 8 GitLab Migration User 2019-12-03 20:15:29 UTC

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-salut/issues/29.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.