Bug 35619 - Gets really confused if a nick conflict occurs when joining a GTalk MUC
Summary: Gets really confused if a nick conflict occurs when joining a GTalk MUC
Status: RESOLVED FIXED
Alias: None
Product: Telepathy
Classification: Unclassified
Component: gabble (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Telepathy bugs list
QA Contact: Telepathy bugs list
URL: http://cgit.collabora.co.uk/git/user/...
Whiteboard:
Keywords: patch
Depends on: 35120
Blocks:
  Show dependency treegraph
 
Reported: 2011-03-24 03:50 UTC by Will Thompson
Modified: 2011-04-21 09:14 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Description Will Thompson 2011-03-24 03:50:31 UTC
I had an issue where Gabble got really confused when I tried to join a GTalk-hosted MUC but there was already someone else in the room (namely myself) with the nick ‘wjt’.

It seems to be triggered by Google's server sending the <presence type='error'>...<conflict/></p> stanza *twice* for the nick that's in use; Gabble/Wocky (not sure which is at fault yet …) gets really messed up when it receives the second one.
Comment 1 Will Thompson 2011-03-24 03:59:34 UTC
(I'm working on this, so stealing the bug.)
Comment 2 Will Thompson 2011-03-24 04:04:10 UTC
(Specifically, when it gets the first rejection for ‘wjt’, Gabble tries ‘wjt_’; when it gets the second rejection for ‘wjt’ it *also* tries ‘wjt__’ and then everyone dies.)
Comment 3 Will Thompson 2011-03-25 07:58:28 UTC
Here's a fix. It's atop a different MUC fix for no good reason.
Comment 4 Will Thompson 2011-03-31 11:47:28 UTC
assigning back to the list in the hope that someone sees and reviews it!
Comment 5 Jonny Lamb 2011-04-04 07:38:45 UTC
+ # As far as Gabble's concerned, the two other participants joined
+ # immediately after we did.
+ handle, handle_, handle__, foobar_handle = conn.RequestHandles(
+ cs.HT_CONTACT, jids + ['%s/foobar_gmail.com' % room_jid])
+ q.expect('dbus-signal', signal='MembersChangedDetailed',
+ predicate=lambda e: e.args[0:4] == [[foobar_handle], [], [], []])
+ q.expect('dbus-signal', signal='MembersChangedDetailed',
+ predicate=lambda e: e.args[0:4] == [[handle], [], [], []])

This looks as if it could be racy. What if the MCD signals apear before RequestHandles returns?

Everything else looks good.
Comment 6 Will Thompson 2011-04-04 09:46:05 UTC
(In reply to comment #5)
> + # As far as Gabble's concerned, the two other participants joined
> + # immediately after we did.
> + handle, handle_, handle__, foobar_handle = conn.RequestHandles(
> + cs.HT_CONTACT, jids + ['%s/foobar_gmail.com' % room_jid])
> + q.expect('dbus-signal', signal='MembersChangedDetailed',
> + predicate=lambda e: e.args[0:4] == [[foobar_handle], [], [], []])
> + q.expect('dbus-signal', signal='MembersChangedDetailed',
> + predicate=lambda e: e.args[0:4] == [[handle], [], [], []])
> 
> This looks as if it could be racy. What if the MCD signals apear before
> RequestHandles returns?

It does look suspicious. But libdbus/dbus-python (I forget which) reorders messages when making blocking calls, so it's actually safe.
Comment 7 Will Thompson 2011-04-21 09:14:37 UTC
http://cgit.freedesktop.org/telepathy/telepathy-gabble/commit/?id=18fb2c20f26b9ee8d4fbb67f47cf374752b866bc

Will be in 0.11.11 (or 0.12.0 if I decide to call it that).


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.