Inexplicable Variant wrapping of D-Bus property.

[mulkieran]

Hi,

I'm experiencing an artefact where some tools that interrogate the D-Bus service think that the signature of a property is a Variant containing a type X, and others think that it is the bare type X.

Compare the following:

[mulhern@dhcp-25-209 stratisd-client-dbus]$ busctl --user get-property org.storage.stratis1 /org/storage/stratis1 org.storage.stratis1.Manager RedundancyCodes
a(sq) 1 "RAID0" 0

From QT5DbusViewer

Received reply from :1.6899
  Arguments: [Variant: [Argument: a(sq) {[Argument: (sq) "RAID0", 0]}]]

From dbus-python

(Pdb) Manager.Properties.RedundancyCodes(self._proxy)
dbus.Array([dbus.Struct((dbus.String('RAID0'), dbus.UInt16(0)), signature=None)], signature=dbus.Signature('(sq)'), variant_level=1)

Note how the bottom 2 think that they're dealing with a variant type, while busctl does not seem to.
Note also that it is not the type within the array that is a variant, but the array itself.

Have you heard of this and do you think it's likely that it is a result of some dbus-rs behavior? I had originally ruled that out, because busctl does not indicate that the result is a variant. But I have also noticed that you have a publicly defined get_as_variant() method on the Property, and I'm not sure of its purpose or when it might be called.

Please let me know if you have any thoughts,

Thanks!

[diwic]

get_as_variant is called internally, don't worry about it. Properties are always encapsulated in variants when sent over D-Bus, so probably "busctl" knows about this and automatically recurses the variant for you. After all, you seem to call "get-property" on "busctl" rather than specifying the interface and member yourself, so it seems "busctl" has some built in support for getting properties.

[mulkieran]

Huh! Thanks for letting me know about that one. Now I just wish I knew why ;)