Skip to content

failure making a method call: the call may be wrapped in an extra tuple

I have a simple reproduction program showing inability to make a dbus call:

use std::error::Error;
use zbus::dbus_proxy;
use zvariant::{Str, Value};
 
#[dbus_proxy(
    interface = "org.freedesktop.Secret.Service",
    default_service = "org.freedesktop.secrets",
    default_path = "/org/freedesktop/secrets"
)]
trait Service {
    /// OpenSession method
    fn open_session(
        &self,
        algorithm: &str,
        input: &zvariant::Value,
    ) -> zbus::Result<(zvariant::OwnedValue, zvariant::OwnedObjectPath)>;
}
 
fn main() -> Result<(), Box<dyn Error>> {
    println!("Hello, world!");
    println!("a");
    let connection = zbus::Connection::new_session()?;
    println!("b");
 
    let proxy = ServiceProxy::new(&connection)?;
    println!("c");
    let reply = proxy.open_session("plain", &Value::Str(Str::from("")))?;
    println!("d");
    dbg!(reply);
 
    Ok(())
}

the output of the app is:

Hello, world!
a
b
c
Error: Message(UnmatchedBodySignature)

I discussed this issue with BilalElmoussaoui on IRC, he suggested adding dbg! entries at https://gitlab.freedesktop.org/zeenix/zbus/-/blob/master/zbus/src/message.rs#L476

They showed that: b_sig = "(vo)" sig.as_str() = "vo"

So zbus appears to be expecting me to wrap the parameters in a tuple. If I do that, the check passes, but then when the call is done, I get:

Error: MethodError("org.freedesktop.DBus.Error.InvalidArgs", Some("Type of message, “((sv))”, does not match expected type “(sv)”"), Msg { type: Error, sender: ":1.29", reply-serial: 2, body: Signature: [
	s (115),
] })

And now we see ((sv)) so it seems zbus wrapped my tuple with another tuple.

BilalElmoussahoui thought it may be related to https://gitlab.freedesktop.org/zeenix/zbus/-/merge_requests/171

Maybe an extra bit of information that may or may not help: if I declare the proxy without a tuple (as in the code sample I pasted in this bug report), and comment the check on the body signature in zbus, then the call does succeed.

Edited by Emmanuel Touzery