BRPOPLPUSH return type is contingent on success

[GoogleCodeExporter]

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. 

Original issue reported on code.google.com by teb...@gmail.com on 29 Aug 2011 at 8:59

[GoogleCodeExporter]

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?

Original comment by pcnoordh...@gmail.com on 30 Aug 2011 at 3:57

• Changed state: Accepted

[GoogleCodeExporter]

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.

Original comment by teb...@gmail.com on 30 Aug 2011 at 8:54