Steps to reproduce: 1. MC disconnect while the event loop of a CM is blocked (in my case, The One Ring) 2. MC create a new connection Expected Behavior The Connection cleans up cleanly and a new one is able to be created Actual Behavior The connection is leaked. Some CMs don't randomize the Connection name, preventing future connections from being made. From Mikhail: """ For one thing, I think Mission Control should keep watch on lingering connections even after it has ceased doing anything useful with them, and react to the connection status signals. If the connection comes online after all, it could be treated positively, or it could be immediately told to disconnect just to not muddle the MC state too much. A bug on bugs.freedesktop.org could be filed. """ My own ramblings without knowing the code: If MC waited on recreating a connection until it got Disconnect this would help in the case where Disconnect doesn't block but the event loop is blocked from other processing. The Disconnected signal would fire, causing a RequestConnection. I imagine there is possibility of negative impact with this. I'm also guessing it would be bad to generally monitor for NewConnection and respond to it regardless of an outstanding RequestConnection. This would help in the case of the CM event loop blocking at some point (pre-Disconnect, Disconnect, RequestConnection) and allow cleaning up of that resource. For more information, see the following thread on Telepathy mailing list http://lists.freedesktop.org/archives/telepathy/2010-March/004343.html
-- 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/22.
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.