What version of Redis you are using, in what kind of Operating System?

Redis 2.2.12 on Mac OS 10.6.8

What is the problem you are experiencing?

BRPOPLPUSH returns a bulk reply when an element is successfully popped and pushed, but returns a (null) multi-bulk reply otherwise. This seems inconsistent with every other command I've used -- including RPOPLPUSH -- where the return type is fixed regardless of success or failure. Why not return a null bulk reply in the failure case like RPOPLPUSH does?

The return type behavior is documented at http://redis.io/commands/brpoplpush, so I assume it is intentional.

What steps will reproduce the problem?

Send the command "BRPOPLPUSH listA listB 1", where listA is an empty list.

I agree that this should be consistent. Thanks for noticing.

The reason it is not right now is that it shares timeout code with the regular blocking pops, which in fact do emit a null multi bulk on timeout. In my opinion this is only cosmetic, since both the null bulk and null multi bulk means some kind of null value (unlike the empty bulk/string vs the empty multi bulk/array). Does the client you use return different objects for these two types of null replies?

I've only used the redis-rb client before, which does return nil for any null reply.

The reason I'm noticing the issue now is that I'm writing my own client in a statically typed language, Haskell. Because of type inference and a mapping that I define from Redis reply types to common Haskell types, if I declare that my client's brpoplpush function returns the common type IO (Maybe String) (i.e., a string that can be null), then it can be inferred at compile time that a bulk reply should be read from the socket.

I worked around the BRPOPLPUSH issue by changing my type mapping so that IO (Maybe String) can be coerced from either a bulk reply or a null multi-bulk reply. However, having a guaranteed reply type for each command is a nice property, and I figured that it would be worth pushing for if BRPOPLPUSH is the only exception.