Describe the bug

A command that has a small timeout, like 1 millisecond, gets treated like 0 - which is infinitely blocking and very different than expected.

To reproduce

> BLMOVE k1 k2 left right 0.002
(nil)
> BLMOVE k1 k2 left right 0.001
... blocks indefinitely

Expected behavior

If non-zero timeout is specified, the command should not infinitely block.

Additional information

Comment From: enjoy-binbin

fixed in #11688, can you try 7.0.8?

Comment From: jimsnab

Yes this the version I have.

Redis server v=7.0.8 sha=00000000:0 malloc=jemalloc-5.2.1 bits=64 build=8b9bd5cdb53a6549

Comment From: jimsnab

Apparently just merged 2 days ago, so it must be coming in 7.0.9.

Comment From: enjoy-binbin

Apparently just merged 2 days ago, so it must be coming in 7.0.9.

It's already in 7.0.8, see #11718 is there still a problem in your machine? can you post more info like (OS distribution. etc)

Comment From: jimsnab

Must have been some timing with updates on my end, it is working now.

Comment From: jimsnab

Off topic from this, but I don't want to start a new issue for this minor question - should a negative timeout block?

Comment From: itamarhaber

... should a negative timeout block?

The very idea of a negative timeout is weird, and there's no intuitive way to interpret it imo. If I rewrite Redis from scratch, valid blocking timeout values would be either 0 or a positive integer as number of msecs. Ideally, negative values should raise an -ERR. Less ideally, negatives should be silently treated as non-blocking.

Comment From: enjoy-binbin

yean, i think it should throw an error, like blpop, raise an -ERR:

127.0.0.1:6379> blpop key -1
(error) ERR timeout is negative