Adium

Ticket #1874 (closed defect: fixed)

Opened 5 years ago

Last modified 2 years ago

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

Reported by: fenner@fenron.com Owned by: evands
Milestone: Adium 1.3 Component: Service/Jabber (XMPP)
Version: 1.0svn Severity: major
Keywords: WasOn1.5 Cc:
Patch Status:

Description

If you try to join a Jabber group chat using a "Handle" that already exists in the chat, you will get a '409 conflict' error from the Jabber server. Adium reports this properly, but once this error has been received, it's no longer possible to join that chat room (e.g., after picking a different handle) - no error is reported, and no chat window appears. Joining other rooms on the same server works, as does joining rooms on different servers.

(What I'm running calls itself 0.9svn, which isn't in the Version: list)

Change History

  Changed 5 years ago by boredzo

  • version changed from 0.85 to 1.0svn

  Changed 5 years ago by fenner@…

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

  Changed 5 years ago by catfish_man

  • milestone set to Adium X 1.5

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

  Changed 5 years ago by boredzo

  • summary changed from After 409 Conflict error, it's impossible to join another Jabber group chat to After 409 Conflict error, it's impossible to join the same Jabber group chat

fixed summary.

  Changed 3 years ago by am

  • patch_status set to None
  • pending set to 0
  • field_haspatch set to 0

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.

  Changed 3 years ago by evands

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.

  Changed 3 years ago by tick

  • keywords WasOn1.5 added
  • milestone changed from Adium X 1.5 to Good idea for "later"

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.

follow-up: ↓ 14   Changed 3 years ago by erik006

  • priority changed from normal to high
  • severity changed from normal to major

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

  Changed 3 years ago by erik006

  • status changed from new to closed
  • resolution set to duplicate

  Changed 3 years ago by am

Duplicate of which ticket?

  Changed 3 years ago by erik006

  • status changed from closed to reopened
  • resolution duplicate deleted

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

Erik

in reply to: ↑ description   Changed 3 years ago by fenestro

Replying to fenner@research.att.com:

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

  Changed 3 years ago by evands

  • reporter changed from fenner@… to fenner@…

in reply to: ↑ 8   Changed 3 years ago by Robby

  • milestone changed from Good idea for "later" to Adium X 1.3

Replying to erik006:

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

  Changed 2 years ago by evands

  • owner changed from nobody to evands
  • status changed from reopened to new

  Changed 2 years ago by evands

  • status changed from new to closed
  • resolution set to fixed

(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.

Note: See TracTickets for help on using tickets.