Is org.freedesktop.DBus.Error.NoReply the same as timeout?

[Simon McVittie]

On Wed, 04 Sep 2019 at 08:42:43 -0700, Thiago Macieira wrote:
> [NoReply] is synthesised by either the 
> daemon or by the D-Bus library you're using when a timeout did happen. But 
> there are other cases when it happens too, such as when the called service 
> disconnects before replying. Notably, it happens when the connection to the 
> bus fails too.

You get the NoReply error whenever the D-Bus framework has given up on
getting the expected reply (the clue's in the name). This currently means:

- When you set a client-side timeout other than DBUS_TIMEOUT_INFINITE,
  if that timeout is reached and you have still not received a reply,
  the client-side library delivers a NoReply error and stops waiting for
  a reply. In libdbus, using a timeout of -1 means use a reasonable
  default (currently 25 seconds). Other D-Bus libraries usually have a
  similar design.

  The human-readable error message starting with
  "Did not receive a reply. Possible causes include:" indicates that
  it was this event that was observed in this case.
  (The exact message is not an API guarantee, do not rely on it - but
  it can be useful when you're debugging.)

- When the dbus-daemon has configured a timeout, if *that* timeout is
  reached and the service has still not sent a reply, the dbus-daemon
  delivers a NoReply error to the client and stops waiting for a reply.
  The reference dbus-daemon uses error message
  "Message did not receive a reply (timeout by message bus)" for this.
  (Again, the exact message is not an API guarantee, do not rely on it.)

- If the service disconnects from the dbus-daemon while clients are
  waiting for a reply, the dbus-daemon delivers a NoReply error as a
  response to each method call that was still waiting for a reply.
  The reasoning here is that the service has gone away, so there will never
  be a reply. Since 2014, the reference dbus-daemon uses error message
  "Message recipient disconnected from message bus without replying".
  (Once more, the exact message is not an API guarantee, do not rely on it.)

If the *client* disconnects from the dbus-daemon, you currently get a
different machine-readable error name, o.fd.DBus.Error.Disconnected, on
all method calls that were still waiting for their replies.

> So it's more than a timeout. But you can probably behave the same way in all 
> conditions as a result of this.

More precisely, if the designers of these bits of the D-Bus protocol
thought you might need to behave differently in these situations,
they would have used different machine-readable error names instead of
reusing NoReply.

> There's an upper limit defined in the bus's configuration file. I think that 
> defaults to 5 minutes.

It was 5 minutes by default before 2009. Now the default is infinite,
meaning only the client-side timeout is used, unless you have reconfigured
your dbus-daemon.

> If the API you're designing has a chance of reaching 30 seconds between 
> call and reply, you should redesign it so that it returns immediately saying 
> "job started" and report conclusion later with a (directed) signal or a 
> callback. This will also allow you to emit signals with progress reports.

This is often a good design, but is not strictly required.

If your API's calls take more than a couple of minutes, then you probably
also need to think about what is going to happen if the user logs out and
back in (destroying and re-creating their session bus, and terminating and
restarting all their UI processes) while the operation is still ongoing.

    smcv