Proper handling of the dbus call method timeout

Hi All,

We bumped into an issue with handling timeout for pending method
calls. We are using dbus_connection_send_with_reply with custom
timeout (e.g. 1 second) and due to a bug in the dbus method provider
it hung, thus was not sending a reply. This led to an error reply on
the client side: "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". However after 128 tries to call the method the
error changed to "The maximum number of pending replies per connection
has been reached" and the client was not able to perform any dbus
calls anymore (note also that we are using system bus, which has
default configuration of max_replies_per_connection=128). After
checking the dbus source code I see that the first error is generated
by libdbus and the second one by dbus-daemon. Thus it looks like even
though the timeout has been passed to libdbus and the reply error has
been generated, dbus-daemon still tracks pending reply even after the
timeout is reached. Is there a way to cancel pending call in the
dbus-daemon queue? Alternatively, what is the supposed way to handle
the case with missing replies on the client side (as the bug is
actually on the method provider side, but method client is unable to
perform bus calls after some tries)?

Thank you,
Anton.