Created attachment 31863 [details] gabble log Hi, From what I understood, calling EnsureChannel will create a channel for us, and if the channel already exists, it will give us the channel with yours=false. however, this does not seem to work. I've been struggling with this for a couple of days before realizing the bug comes from gabble. If I call EnsureChannel (on the Account), when a channel already exists, I will never get an answer from gabble. I'm attaching a log from gabble taken with GABBLE_DEBUG=all WOCKY_DEBUG=all. What I do is connect my account in empathy, then join a MUC in empathy, then I run teamgeist which tries to join the MUC by calling EnsureChannel. The request is never answered. Sometimes (didn't seem to happen in this particular case, even though I waited about 10 minutes), I get after a long timeout the signal Failed on the ChannelRequest with the message (the 'error' argument being empty) : "Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken." By the way, since I'm doing a lot of testing by launching teamgeist/ctrl-c/launch/ctrl-c/etc.. I can sometimes reproduce this bug without even opening the MUC in empathy, and with dbus-monitor I see the StatsChanged signal with ChannelCount reporting many channels (text or dbustube), which seem to mean that sometimes a channel is not destroyed even if the process that requested it got killed... so there's a channel leak here, and it prevents me from continuing without killing gabble.
Created attachment 31864 [details] mission-control log humm... from the dbus-monitor log, it looks like the EnsureChannel is answered by gabble, but mission control doesn't do anything with it.. I'm attaching mission control log, hoping it will help... it was captured with MC_DEBUG=all MC_TP_DEBUG=all (note that I do two EnsureChannel, the first one is done on a disabled account, so it's easy to find the pertinent log, just look for the "account isn't Enabled" debug message at the end of the log.. my EnsureChannel came right after that).
Created attachment 31865 [details] dbus-monitor log Attaching dbus-monitor log this time
I'm pretty sure and I saw it multiple times, that gabble itself simply doesn't answer to the EnsureChannel sent by mission-control on the Connection. But since I can't reproduce it anymore, and I only have logs for the problem with mission control, I'm changing the summary and component of the bug to mission-control. Note: That Failed signal on ChannelRequest with message "Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken." was probably appearing only on the bug when gabble doesn't answer EnsureChannel..
-- 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-mission-control/issues/18.
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.