Bug 35619

Summary:	Gets really confused if a nick conflict occurs when joining a GTalk MUC
Product:	Telepathy	Reporter:	Will Thompson <will>
Component:	gabble	Assignee:	Telepathy bugs list <telepathy-bugs>
Status:	RESOLVED FIXED	QA Contact:	Telepathy bugs list <telepathy-bugs>
Severity:	normal
Priority:	medium	Keywords:	patch
Version:	unspecified
Hardware:	Other
OS:	All
URL:	http://cgit.collabora.co.uk/git/user/wjt/telepathy-gabble-wjt.git/log/?h=fd.o-35619-gtalk-muc-conflicts
Whiteboard:
i915 platform:		i915 features:
Bug Depends on:	35120
Bug Blocks:

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.