[Bug 77986] When Delegating handlers are given a Requests_Satisfied path that doesn't exist

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=77986

--- Comment #1 from Simon McVittie <simon.mcvittie at collabora.co.uk> ---
(In reply to comment #0)
>  - MC sends sends a HandleChannels call to my AppB with a all the normal
> stuff and a path to the ChannelDispatcherRequest path as the
> Requests_Satisfied:
> @ao ["/org/freedesktop/Telepathy/ChannelDispatcher/Request24"]

You're right, that sounds like a MC bug: the request finished ages ago, so we
shouldn't be referring to it any more.

>  - TpQt does it's introspection and tries to load the request from the
> ChannelDispatcher
>  - it fails with "GetAll" with signature "s" on interface
> "org.freedesktop.DBus.Properties" doesn't exist"
>  - TpQt then explodes and ignores the request.

I think this is also a TpQt bug, or possibly design flaw (but perhaps one that
you can't fix without breaking API, so you might need to fix it in 'next'). In
telepathy-glib we deliberately didn't require, or wait for, the ChannelRequest
to prepare successfully, because it takes a round-trip and approximately nobody
is going to need it.

The main purpose of Requests_Satisfied is matching up channels you're being
asked to handle with either requests you started (if you create/ensure
channels), or channels whose channel request you were previously asked to
approve (if you're an Observer or Approver). If you're doing either of those,
you have a TpChannelRequest already, it's probably already prepared too, and
all you need to do is match it by object path or by object identity, for
instance looking it up in a hash table { channel request => chat window }.

If you're not doing either of those, HandleChannels seems too late for the
channel request to be useful.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.