Fail when calling a method accepting a struct as argument

[zeenix]

In GitLab by @DataTriny on Mar 22, 2021, 21:07

Hello,

I am trying to call the following method:

<interface name="org.a11y.atspi.Socket">
  <method name="Embed">
    <arg direction="in" name="plug" type="(so)"/>
    <arg direction="out" name="socket" type="(so)"/>
  </method>
</interface>

For which I defined a proxy:

#[dbus_proxy(interface = "org.a11y.atspi.Socket")]
trait Socket {
    fn embed<'a>(&self, plug: (&str, &zvariant::ObjectPath<'a>)) -> zbus::Result<(String, zvariant::OwnedObjectPath)>;
}

However, when I call it like this:

let root_path = ObjectPath::try_from("/org/a11y/atspi/accessible/root").unwrap();
let root_path_cloned = root_path.clone();
let socket_proxy = SocketProxy::new_for(&conn, "org.a11y.atspi.Registry", &root_path).unwrap();
socket_proxy.embed((conn.unique_name().unwrap(), root_path_cloned)).unwrap();

The remote service does not reply as expected because the outgoing message is wrong. Here is how it look like when captured by dbus-monitor:

method call time=1616439187.527337 sender=:1.314 -> destination=org.a11y.atspi.Registry serial=2 path=/org/a11y/atspi/accessible/root; interface=org.a11y.atspi.Socket; member=Embed
   string ":1.314"
   object path "/org/a11y/atspi/accessible/root"

As you can see, the string and the path are sent without being contained in a struct. Replacing the tuple by a struct with two fields give the same result.

This code used to produce the expected behavior with version 1.8.0 of zbus, but I had to switch to 2.0.0-beta.3 because I need to both read from and write to the DBus connection at the same time.

Did I miss a migration note, or is it a bug?

Thanks in advance for your help.

[zeenix]

Thanks so much for reporting and providing all the details.

Did I miss a migration note, or is it a bug?

Yeah, it's a regression. I thought these issues are behind us but seems we don't. :( I'll look into this soon.

[zeenix]

mentioned in commit b4d8e726bf98daa9dc13b5fe2f8d3e7faa4060be

[zeenix]

mentioned in commit b3385331065c33a0f315e65eaf0d7f88eb72b078

[zeenix]

In GitLab by @DataTriny on Mar 23, 2021, 20:25

Thank you very much @zeenix for this quick fix. I will test it as soon as possible!

[zeenix]

Thank you very much @zeenix for this quick fix.

You're welcome. :)

I will test it as soon as possible!

That'd be great but given that I added an explicit test case that was failing before my fix, I'm certain it works. :)