bugfix: reading from a silent stream should not fail with RedisCommandTimeoutException

[arturaz]

If the stream has no data for a long time, lettuce will throw RedisCommandTimeoutException.

In that case we don't want to fail the stream and we should restart the read.

Alternatively we should use the lettuce reactive API, but that requires quite a large of a refactoring.

[yisraelU]

TY

[yisraelU]

@arturaz I think I was a bit too hasty, I have had more time to look at this in detail.
Can you clarify in your scenario

• Whether the BLOCK option was used.
• If used, what timeout value was specified.

If block was not used , then a timeout exception occurred most likely due to underlying network latency issues (as you can see from the myriad of issues raised here

In that case perhaps this should be viewed as a feature and require opt in by the user

I would also expect in the test scenario added, where one explicitly sets a timeout in the client options, the stream would be shutdown in that case.

updated above

[arturaz]

Whether the BLOCK option was used.

My case uses default option, which is Some(Zero), meaning blocking indefinitely. But yeah, if there is no block, it should return immediately and suppressing the exception is bad.

I will take a look at rewriting this using the reactive redis API instead of async one to see if that helps.

[arturaz]

I migrated streaming to reactive Lettuce API, which, unfortunately, still raises the timeout exception if the stream is silent.

However, I still think it's a better option than repeatedly polling using async API. The simple use case (without restarts) is very straightforward now.

I also added restartOnTimeout: Option[FiniteDuration => Boolean] = None as an option to read.

[yisraelU]

Putting aside the switch to the Reactive API, as you are correct , as noted , it wont solve this problem.
The problem is inherent to how Lettuce works. Lettuce has 2 separate timeout configs .

• Connection timeouts
• Command timeouts

Using the default configs for a client would result in having a CommandTimeout set to 60 seconds as its inherited by default from the connection config which has a default of 60 seconds
The timeout options are set in Lettuce here

The command timeout mechanism is ignorant of the api choice (sync/async/reactive) and will timeout regardless .
One must either change the command timeout config duration, configure it to ignore certain commands, or not use a blocking command .

See this for discussion around CommandTimeout for blocking commands

In fact in the history of Redis4Cats , there is discussion if this was a wise decision to set block to 0 as default.

[arturaz]

So is there a problem with the added feature?