Properties.Get fallibility

[David Rheinsberg]

Hi

On Thu, Jul 27, 2023, at 5:04 PM, Illia Volchanetskyi6439 wrote:
> Is replying with an error to an org.freedesktop.DBus.Properties.Get 
> call okay? I assumed that it was and now I am running into some 
> difficulties.

It is definitely ok to reply with an error. I think the bigger question is what exactly the cascading effect will be. The `Properties` interface is designed to allow a very heterogeneous set of properties on a single interface. The batch-method `GetAll` and the signal `PropertiesChanged` all allow omitting individual values from their result. An implementation is recommended to make use of this rather than failing a call (but it is not required to).

The sd-bus interface, as an example, allows marking fields to:
 - be of constant value
 - never trigger `changed` notifications
 - send `changed` notifications, but not include the value (called 'invalidation')
 - be omitted from batch-requests (called 'explicit')

So it is already very common to have a quite heterogeneous set or properties. The most important aspect is to be stable in how an individual field is reported, because clients might rely on fields being included, or not, in a batch-call.

> I am not sure if this statement covers the case where an error occurs 
> (due to some failure, not just denied access) while trying to read one 
> of the properties. It probably does not. The library that I am using, 
> which implements GetAll for me, replies with the error to GetAll calls 
> in this case, which makes GetAll less useful as the "client" would have 
> to fall back to reading the properties one by one with Get.

This is a valid decision for a library to make. Similarly, a library is free to decide to drop fields on error, but still continue serving the `GetAll` request.

If you want to keep using the library, I suggest looking for flags similar to sd-bus that allow you to suppress individual fields from `GetAll`. That is, if a field is fallible, you can decide to never include it in batch-calls but require explicit calls.

> If I recall correctly, busctl introspect would even omit the interface 
> from the output if one of its properties failed to read.

Yeah, it suppresses values in a lot of situations, to ensure that you do not unnecessarily read large blobs etc.

> The last issue is InterfacesAdded not being emitted, which I am relying 
> upon. The signal must include the properties and their values. 
> Similarly to GetAll, the expected behaviour in case of an error is not 
> clear to me. Not sending the signal at all does not look good to me.

This is part of the ObjectManager interface, rather than the Properties interface, so this requires separate setup, right?

David