CODEWITHSUNDEEP
redisrust
cmedeiros
cmedeiros

Reputation: 584

Wrong number of arguments when using mget with redis-rs

I'm trying to access Redis using Rust with the following:

extern crate redis;

use redis::{Client, Commands, Connection, RedisResult};

fn main() {

    let redis_client = Client::open("redis://127.0.0.1/").unwrap();
    let redis_conn = redis_client.get_connection().unwrap();

    let mut keys_to_get = vec![];
    keys_to_get.push("random_key_1".to_string());
    keys_to_get.push("random_key_2".to_string());
    let redis_result: String = redis_conn.get(keys_to_get).unwrap();
}

When I run cargo run I get:

     Running `target/debug/test_resdis`
thread '<main>' panicked at 'called `Result::unwrap()` on an `Err` value: An error was signalled by the server: wrong number of arguments for 'get' command', ../src/libcore/result.rs:746
note: Run with `RUST_BACKTRACE=1` for a backtrace.
error: Process didn't exit successfully: `target/debug/test_resdis` (exit code: 101)

Am I doing something wrong, or is it a bug?

Upvotes: 3

Views: 2841

Answers (1)

Shepmaster
Shepmaster

Reputation: 430921

Running your program against a netcat server shows the following requests made:

*3
$3
GET
$12
random_key_1
$12
random_key_2

The GET command should be an MGET.

I believe this to be a bug in the implementation:

impl<T: ToRedisArgs> ToRedisArgs for Vec<T> {
    fn to_redis_args(&self) -> Vec<Vec<u8>> {
        ToRedisArgs::make_arg_vec(self)
    }
}

impl<'a, T: ToRedisArgs> ToRedisArgs for &'a [T] {
    fn to_redis_args(&self) -> Vec<Vec<u8>> {
        ToRedisArgs::make_arg_vec(*self)
    }

    fn is_single_arg(&self) -> bool {
        ToRedisArgs::is_single_vec_arg(*self)
    }
}

Under the hood, the library inspects the key type to know if it's multivalued or not, using ToRedisArgs::is_single_arg, which has a default implementation of true.

As you can see, a slice implements ToRedisArgs::is_single_arg, but a Vec does not. This also suggests a workaround: treat the vector like a slice:

redis_conn.get(&*keys_to_get)

This issue has now been filed with the library.

Upvotes: 3

Related Questions