When trying to read optional org.mpris.MediaPlayer2.Player properties such as LoopStatus or Shuffle, or any non-existent property, the client call blocks indefinitely and never returns.
Steps to reproduce
Run Cozy, then try to read optional or any non-existent property from org.mpris.MediaPlayer2.Player interface, for example:
The command won't return nor print anything. The same happens when trying to read properties with zbus.
The expected behavior would be to return an error.
System Information
Operating System: ArchLinux
Installation source: Flathub
Version of cozy: 1.2.1
Possible root-cause and fix
I believe this is due to errors being handled not according to D-Bus specs: from what I can see, Cozy's MPRIS implementation returns Nonewhen the property isn't found or upon other errors. And as I was just told by zbus author, and from what I can see in D-Bus type system spec, None doesn't really map to D-Bus types, which presumably causes clients to block waiting for a supported value.
As I understand, the correct way would be to use return_dbus_error or return_error_literal upon errors instead of invocation.return_value(None). Internally it results in a different D-Bus message type (ERROR instead of METHOD_RETURN).
Bug/Feature description
When trying to read optional
org.mpris.MediaPlayer2.Player
properties such as LoopStatus or Shuffle, or any non-existent property, the client call blocks indefinitely and never returns.Steps to reproduce
Run Cozy, then try to read optional or any non-existent property from
org.mpris.MediaPlayer2.Player
interface, for example:The command won't return nor print anything. The same happens when trying to read properties with zbus.
The expected behavior would be to return an error.
System Information
Possible root-cause and fix
I believe this is due to errors being handled not according to D-Bus specs: from what I can see, Cozy's MPRIS implementation returns
None
when the property isn't found or upon other errors. And as I was just told by zbus author, and from what I can see in D-Bus type system spec,None
doesn't really map to D-Bus types, which presumably causes clients to block waiting for a supported value.As I understand, the correct way would be to use return_dbus_error or return_error_literal upon errors instead of
invocation.return_value(None)
. Internally it results in a different D-Bus message type (ERROR
instead ofMETHOD_RETURN
).