XREAD BLOCK Not Async when Most Recent Message is Deleted

[Jack Maris]

Consider the following scenario: you have a stream and you delete the most recent entry. Then before a new entry is added you call XREAD BLOCK with the new most recent stream id, ie what was the penultimate stream id before. The documented behavior is to block until either a message is added or the block duration times out. However, we consistently observe that redis will immediately return an empty list. We observed this on 5.0.6 and 5.0.9. A fix seems to have been merged into 5.0 RC5 (eea0d3c5) but it does not seem to be in master. 

We have replicated it with the following (run on 5.0.9):

> XADD a_stream * foo bar
"1590977447146-0"

> XADD a_stream * baz bloop

"1590977479145-0"

> XREAD BLOCK 10000 STREAMS a_stream 1590977479145-0
# it waits 10 seconds then returns nil
> XDEL a_stream 1590977479145-0
(integer) 1
> XREAD BLOCK 10000 STREAMS a_stream 1590977447146-0

1) 1) "a_stream" # returned immediately

   2) (empty list or set)

Please let me know if more context would be useful.

[Benjamin Sergeant]

Is that fix not in redis 6 ? redis 6 is GA now.

--
You received this message because you are subscribed to the Google Groups "Redis DB" group.
To unsubscribe from this group and stop receiving emails from it, send an email to redis-db+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/redis-db/4e96aeac-8c91-44dc-acb9-75b3b61d8772%40googlegroups.com.

[Jack Maris]

Yes this does seem to be fixed in 6.0.4. Are bugfixes not making it into 5?

On Monday, June 1, 2020 at 1:10:43 PM UTC-4, Benjamin Sergeant wrote:

Is that fix not in redis 6 ? redis 6 is GA now.

On May 31, 2020, at 7:25 PM, Jack Maris <jack...@gmail.com> wrote:

Consider the following scenario: you have a stream and you delete the most recent entry. Then before a new entry is added you call XREAD BLOCK with the new most recent stream id, ie what was the penultimate stream id before. The documented behavior is to block until either a message is added or the block duration times out. However, we consistently observe that redis will immediately return an empty list. We observed this on 5.0.6 and 5.0.9. A fix seems to have been merged into 5.0 RC5 (eea0d3c5) but it does not seem to be in master. 

We have replicated it with the following (run on 5.0.9):

> XADD a_stream * foo bar
"1590977447146-0"

> XADD a_stream * baz bloop

"1590977479145-0"

> XREAD BLOCK 10000 STREAMS a_stream 1590977479145-0
# it waits 10 seconds then returns nil
> XDEL a_stream 1590977479145-0
(integer) 1
> XREAD BLOCK 10000 STREAMS a_stream 1590977447146-0

1) 1) "a_stream" # returned immediately

   2) (empty list or set)

Please let me know if more context would be useful.

--
You received this message because you are subscribed to the Google Groups "Redis DB" group.

To unsubscribe from this group and stop receiving emails from it, send an email to redi...@googlegroups.com.

[Itamar Haber]

Important fixes should be backported - thanks for noticing this @Jack. Would you mind creating a corresponding issue over at https://github.com/antirez/redis/issues??

To unsubscribe from this group and stop receiving emails from it, send an email to redis-db+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/redis-db/18adefae-e28f-4876-8369-3d885b8b923a%40googlegroups.com.

--

Itamar Haber Technicalist Evangely Phone: +972.54.567.9692

Disclaimer

The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful.

This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business. Providing a safer and more useful place for your human generated data. Specializing in; Security, archiving and compliance. To find out more Click Here.

[Jack Maris]

Sure thing, just added: https://github.com/antirez/redis/issues/7355

On Tuesday, June 2, 2020 at 9:12:24 AM UTC-4, Itamar Haber wrote:

Important fixes should be backported - thanks for noticing this @Jack. Would you mind creating a corresponding issue over at https://github.com/antirez/redis/issues??

To view this discussion on the web visit https://groups.google.com/d/msgid/redis-db/18adefae-e28f-4876-8369-3d885b8b923a%40googlegroups.com.