Bug 47760 - create_and_handle doesn't work if you get two channels back from a request
Summary: create_and_handle doesn't work if you get two channels back from a request
Status: RESOLVED FIXED
Alias: None
Product: Telepathy
Classification: Unclassified
Component: tp-glib (show other bugs)
Version: git master
Hardware: Other All
: medium normal
Assignee: Telepathy bugs list
QA Contact: Telepathy bugs list
URL:
Whiteboard: libreoffice-tubes
Keywords:
Depends on: 32612 50828
Blocks:
  Show dependency treegraph
 
Reported: 2012-03-23 04:05 UTC by Will Thompson
Modified: 2012-08-28 18:17 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Description Will Thompson 2012-03-23 04:05:37 UTC
From account-channel-request.c:

static void
handle_channels (TpSimpleHandler *handler,
    TpAccount *account,
    TpConnection *connection,
    GList *channels,
    GList *requests_satisfied,
    gint64 user_action_time,
    TpHandleChannelsContext *context,
    gpointer user_data)
{
  TpAccountChannelRequest *self = user_data;
  TpChannel *channel;

  if (G_UNLIKELY (g_list_length (channels) != 1))
    {
      GError error = { TP_ERRORS, TP_ERROR_INVALID_ARGUMENT,
          "We are supposed to handle only one channel" };

      tp_handle_channels_context_fail (context, &error);

But if you create_and_handle a 1-1 Tube channel, sometimes (but not always, apparently…) you get both a Tube and a Tubes back in the same blob. I'm basing this on seeing this debug message in my logs and intuition: I haven't actually looked at the bus traffic and the error message provides no interesting information. (I will add more details to the error shortly.)

11:02          cassidy | let's just kill Tubes channel
11:02          cassidy | (we have to keep them internally in the code but can remove them 
                         from the bus)

Are there any other cases where a request returns a plural reply? I think MUC tubes might be one case.
Comment 1 Jonny Lamb 2012-03-23 10:14:37 UTC
(In reply to comment #0)
> 11:02          cassidy | let's just kill Tubes channel

Yeah I'm trying to get rid of "Tubes" from gabble right now. It's taking a lot lot longer than I'd hoped. :-(
Comment 2 Will Thompson 2012-03-27 02:24:09 UTC
I have worked around this in the LibreOffice tubes code for now by firing off an ensure_channel_async() request for the legacy Tubes channel before any modern DBusTube request. This has no user-visible side-effects.

Jonny tells me he has finished a branch to remove legacy Tubes from Gabble, which will render the workaround unnecessary but harmless.

I just looked into the MUC tubes code in Gabble. It looks like the legacy Tubes channel is announced together with the Text channel in some cases, but modern DBusTube channels are not:

  /* Announce tube channels now */
  /* FIXME: we should probably aggregate tube announcement with tubes and text
   * ones in some cases. */

Which is good news, because it means this bug won't resurface as and when LibreOffice is made to use a MUC. (Users will be startled by a text window appearing in their face, but that's a different bug.)
Comment 3 Jonny Lamb 2012-08-28 13:34:37 UTC
Now that Tubes channels have been removed from Gabble and Salut, and Text and Tube channels are announced separately, this shouldn't be a problem anymore.

I'm closing this bug. Feel free to reopen if I've missed something.
Comment 4 Jonny Lamb 2012-08-28 14:12:43 UTC
(In reply to comment #3)
> …Tubes channels have been removed from Gabble and Salut…

… as of git master. The next versions will be:

telepathy-salut 0.9.0
telepathy-gabble 0.17.1

Hopefully they'll come soon.
Comment 5 Simon McVittie 2012-08-28 18:17:25 UTC
(In reply to comment #0)
> But if you create_and_handle a 1-1 Tube channel, sometimes (but not always,
> apparently…) you get both a Tube and a Tubes back in the same blob.

When it's released, Mission Control 5.13.1 will also cut up plural NewChannels signals into several singular NewChannels signals (Bug #52305), so this has been fixed from two different angles; it'll work if you have a new MC and/or new CMs.


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.