Context
After upgrading to taskiq-redis 1.2.3 and redis-py 8.0.1, workers using ListQueueBroker terminate when the queue remains empty for approximately five seconds.
redis-py 8 changed the default socket_timeout from None to 5 seconds. ListQueueBroker.listen() uses an indefinitely blocking BRPOP, so the socket timeout is reached while it waits for a message.
Environment
- Python: 3.14
- taskiq: 0.12.4
- taskiq-redis: 1.2.3
- redis-py: 8.0.1
- Server: Valkey 9.0.3
Minimal configuration
from taskiq_redis import ListQueueBroker
broker = ListQueueBroker("redis://valkey:6379")Start the worker and leave the queue empty:
taskiq worker module:broker
Observed behavior
After approximately five seconds, BRPOP raises a socket read timeout:
File "taskiq_redis/redis_broker.py", line 132, in listen
brpop_result = await redis_conn.brpop(self.queue_name)
redis.exceptions.TimeoutError: Timeout reading from valkey:6379
The exception propagates through the receiver and the process manager restarts the worker:
worker-0 is dead. Scheduling reload.
worker-1 is dead. Scheduling reload.
This repeats while the queue remains empty.
Explicitly disabling the socket read timeout appears to prevent the restarts:
broker = ListQueueBroker(
"redis://valkey:6379",
socket_timeout=None,
)Questions
Is socket_timeout=None the recommended configuration for ListQueueBroker with redis-py 8?
Should applications configure this explicitly, or is ListQueueBroker expected to account for the indefinitely blocking BRPOP internally, for example by using a finite polling timeout or handling redis.exceptions.TimeoutError?
If explicit configuration is expected, would it make sense to document this interaction?
Related references
I could not find this interaction mentioned in the taskiq-redis 1.2.3 release notes or README.
Context
After upgrading to
taskiq-redis 1.2.3andredis-py 8.0.1, workers usingListQueueBrokerterminate when the queue remains empty for approximately five seconds.redis-py 8 changed the default
socket_timeoutfromNoneto 5 seconds.ListQueueBroker.listen()uses an indefinitely blockingBRPOP, so the socket timeout is reached while it waits for a message.Environment
Minimal configuration
Start the worker and leave the queue empty:
Observed behavior
After approximately five seconds,
BRPOPraises a socket read timeout:The exception propagates through the receiver and the process manager restarts the worker:
This repeats while the queue remains empty.
Explicitly disabling the socket read timeout appears to prevent the restarts:
Questions
Is
socket_timeout=Nonethe recommended configuration forListQueueBrokerwith redis-py 8?Should applications configure this explicitly, or is
ListQueueBrokerexpected to account for the indefinitely blockingBRPOPinternally, for example by using a finite polling timeout or handlingredis.exceptions.TimeoutError?If explicit configuration is expected, would it make sense to document this interaction?
Related references
BRPOPbehavior in redis-py: [BUG] brpop crashes in version 8.0.0 with: redis.exceptions.TimeoutError: Timeout reading from socket exception redis/redis-py#4125timeoutcannot exceed client'ssocket_timeoutredis/redis-py#2807I could not find this interaction mentioned in the taskiq-redis 1.2.3 release notes or README.