fix: add blockingTimeout option for blocking commands

[PavelPashov]

Fixes #1888

[manast]

If I have understood the code correctly, the forced timeout will only be applied if we pass the new blockingTimeout option explicitly. The main issues I see with this approach is that by default the instance can hang forever if the user uses blocking commands, as the watchdog is not enabled when we have a specific timeout argument passed in the Redis command. Also, I was not sure how this setting can be used per command. For example in BullMQ we have different timeouts when we call bzpopmin, depending on the maximum time we want the command to wait until it gives up (this is required by the delayed jobs functionality among other things).

[PavelPashov]

If I have understood the code correctly, the forced timeout will only be applied if we pass the new blockingTimeout option explicitly. The main issues I see with this approach is that by default the instance can hang forever if the user uses blocking commands, as the watchdog is not enabled when we have a specific timeout argument passed in the Redis command. Also, I was not sure how this setting can be used per command. For example in BullMQ we have different timeouts when we call bzpopmin, depending on the maximum time we want the command to wait until it gives up (this is required by the delayed jobs functionality among other things).

You understood it correctly. To begin with, I’d recommend making this an opt-in feature for safety. Supporting per-command options is not straightforward because the command signatures are generated automatically in RedisCommander by this script. A builder pattern or a similar mechanism might offer a more practical way to enable per-command timeouts.

[manast]

So the way to see this new option is like a fallback for this type of disconnections and nothing else. In this case I guess it is ok. I can test it in my setup to see if it solves the problem for us.