Bug 34258

Summary: Pending channel invite prevents you joining the same channel manually
Product: Telepathy Reporter: Ian Molton <ian.molton>
Component: idleAssignee: Telepathy bugs list <telepathy-bugs>
Status: RESOLVED MOVED QA Contact: Telepathy bugs list <telepathy-bugs>
Severity: normal    
Priority: medium CC: rishi.is
Version: unspecified   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments: Proposed fix

Description Ian Molton 2011-02-14 07:13:11 UTC
As summary.

possibly it may block all joins, I didnt try.
Comment 1 Debarshi Ray 2011-03-11 19:14:47 UTC
I am unable to reproduce this. Could you please tell us how to do so? Thanks.
Comment 2 Ian Molton 2011-03-16 11:53:22 UTC
Set up two machines, with two people. label them A and B.

Run Empathy on B

Have A create a new channel and send an invite to B

Have B join the channel by name (NOT by responding to the request).

This will fail reliably here.

(in the process of confirming this bug, I noticed that you cannot re-invite someone to a channel if they accidentally decline the first request, too)
Comment 3 Debarshi Ray 2011-03-20 02:41:31 UTC
Created attachment 44631 [details] [review]
Proposed fix
Comment 4 Will Thompson 2011-04-11 09:32:20 UTC
Review of attachment 44631 [details] [review]:

This is the kind of thing for which a short regression test would be really good; both testing Ian's original case, and the case I'll describe below.

I can't see any way how the channel's state will change to MUC_STATE_JOINING when the join request is sent. So consider the following sequence of events:

1. A contact invites me to #foo.
2. I call EnsureChannel(... #foo ...).
3. Idle sends JOIN #foo to the server.
4. Before the server replies, I decline the invitation. This causes part_from_channel() to be called (by remove_member()); with that patch, that function checks priv->state, finds that the state is CREATED (which is not >= JOINING), and so doesn't bother to send PART; the channel closes.
5. Now the server replies to our JOIN, and we're in the channel, but we didn't want to be.

This seems like a bug.

::: src/idle-muc-channel.c
@@ +1754,3 @@
 	}
 
+	idle_muc_channel_part(obj, priv->connection->parent.self_handle, msg);

Calling this function even if we're waiting for a reply to our PART request is wrong: it means the channel is signalled as closed at the Telepathy level immediately, rather than when the server acknowledges that we've left the channel.

(This is related to my overall point.)
Comment 5 Will Thompson 2012-11-14 19:12:38 UTC
http://cgit.collabora.com/git/user/wjt/telepathy-idle/log/?h=34258-invite is the start of a test + revised fix for this.
Comment 6 GitLab Migration User 2019-12-03 20:09:06 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-idle/issues/25.

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.