After 409 Conflict error, it's impossible to join the same Jabber group chat

Here is some info from the debug log. When first trying to join the chat and getting the conflict error:

Creating chatWithName:blah@conference.psg.com onAccount:<ESGaimJabberAccount: 0x6037a00>:2:fenner@jabber.psg.com chatCreationInfo:{handle = Bill; room = blah; server = "conference.psg.com"; }
[AIChat: 3e96b0 initForAccount]
chatWithName:blah@conference.psg.com onAccount:<ESGaimJabberAccount: 0x6037a00>:2:fenner@jabber.psg.com added <<<AIChat: 0x3e96b0>:<new>>> [<NSCFSet: 0x372440> (<AIChat: 0x3e96b0>:<new>)]
gaim openChat:<AIChat: 0x3e96b0>:blah@conference.psg.com.0 for blah@conference.psg.com.0
Creating a chat.
Danger, Will Robinson! password is in the proto_info but can't be found in {handle = Bill; room = blah; server = "conference.psg.com"; }
In the event of an emergency, your GHashTable may be used as a flotation device...
(Libgaim: jabber) Sending (ssl): <presence to='blah@conference.psg.com/Bill'><x xmlns='http://jabber.org/protocol/muc'/></presence>
(Libgaim: jabber) Recv (ssl)(344): <presence from='blah@conference.psg.com/Bill' to='fenner@jabber.psg.com/Adium' type='error'><x xmlns='http://jabber.org/protocol/muc'/><error code='409' type='cancel'><conflict xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/><text xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'>Nickname is already in use by another occupant</text></error></presence>
adiumGaimNotifyMessage: type: 0
Error joining chat blah@conference.psg.com/Bill
Error joining chat blah@conference.psg.com/Bill
409: Conflict 

(A nice to have would be to have the error dialog display the <text> too, since it says what the *real* error is, but that's a different problem)

The second time I try to join, when the room simply silently fails, the debug log says:

Creating chatWithName:blah@conference.psg.com onAccount:<ESGaimJabberAccount: 0x6037a00>:2:fenner@jabber.psg.com chatCreationInfo:{handle = Bill; room = blah; server = "conference.psg.com"; }

---

P.S. Feel free to set target to 1.5, since this is group chat for sure

Thanks for the logs :) Should make it much easier to track down. I agree, though, that it's best suited for 1.5

fixed summary.

I investigated the cause, and concluded that it's a very complicated design bug in Adium.

This is the important code:

		//Create a new chat
		chat = [AIChat chatForAccount:account];
		[chat setName:name];
		[chat setIdentifier:identifier];
		[chat setIsGroupChat:YES];
		[openChats addObject:chat];
		AILog(@"chatWithName:%@ identifier:%@ onAccount:%@ added <<%@>> [%@]",name,identifier,account,chat,openChats);
		
		if (chatCreationInfo) [chat setStatusObject:chatCreationInfo
											 forKey:@"ChatCreationInfo"
											 notify:NotifyNever];
		
		[chat setStatusObject:[NSNumber numberWithBool:YES]
					   forKey:@"AlwaysShowUserList"
					   notify:NotifyNever];
		
		//Inform the account of its creation
		if (![account openChat:chat]) {
			[openChats removeObject:chat];
			AILog(@"chatWithName: Immediately removed <<%@>> [%@]",chat,openChats);
			chat = nil;
		}
		
		AILog(@"chatWithName %@ created --> %@",name,chat);

Note that the chat gets added to openChats immediately after the -openChat: message is sent. However, in libpurple, it doesn't work that way. You first request joining a chat, and then on success, libpurple creates the chat by itself by calling

(struct _PurpleConversationUiOps).create_conversation(PurpleConversation *conv);

If that callback doesn't get called, the join wasn't successful. This means that there's no way to tell immediatly after sending the -openChat: whether the operation was successful. Further, there's no callback when joining the chat didn't succeed, since libpurple just displays a generic notice as feedback, so the object can't even be removed afterwards on failure.

I think the proper solution is a ui op which is called when a conversation can not be created. This would pass back the account, the name of the chat which was trying to be joined, and perhaps the other fields initially passed which might include a ui_data field for the ui's use.

As the group chat SoC 2007 project completed successfully, we no longer require a group chat milestone. As such, I'm going to move all of these over to Good Idea for "later". Process these normally, reassign as needed to the new 1.x milestones created last night.

This is a major show-stopper if you're using jabber. This really should be addressed. It ties in with ticket #7388. Andreas sent his analysis of this bug to the devl-list in the summer, although i'm not sure if it contains any more info than that in his comment above. May be worth checking out.

Erik

Duplicate of which ticket?

I think I accidently closed this ticket, while meaing to close another. This definitely should be open.

Erik

Replying to fenner@research.att.com:

My email address has changed; if a trac admin wouldn't mind changing the reporter to fenner@fenron.com I'd appreciate being able to keep track of the status of this bug.

Replying to erik006:

This is a major show-stopper if you're using jabber. This really should be addressed. ... Erik

(In [23232]) im.pidgin.pidgin 2.4.2mtn @ b28057d6ade7c221b0616c3b02e86659e2d8b10b which adds a chat-join-failed signal. We then make use of it to know when joining a group chat fails (currently only works for jabber chats) and remove our reference to the corresponding AIChat. Fixes #1874. Fixes #7388.