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