Worker enters restart loop when broker.listen() raises a transient exception

[leonelfreire]

Context

While investigating an issue with taskiq-redis's ListQueueBroker after upgrading to redis-py 8, I noticed that an exception raised by broker.listen() terminates the worker process, after which the process manager immediately schedules a replacement.

The original broker-specific issue is documented here:

• What is the recommended socket timeout configuration for ListQueueBroker with redis-py 8? taskiq-redis#127

In that particular case, redis-py 8 changed its default socket_timeout to 5 seconds while ListQueueBroker performs an indefinitely blocking BRPOP. When the queue remains empty, the Redis client raises redis.exceptions.TimeoutError.

The relevant sequence is roughly:

broker.listen()
  -> BRPOP waits for a message
  -> redis.exceptions.TimeoutError
  -> exception propagates out of the receiver
  -> worker process dies
  -> process manager schedules reload
  -> same thing happens again

Result:

worker-0 is dead. Scheduling reload.
worker-1 is dead. Scheduling reload.

This can result in a continuous worker restart loop while the underlying condition persists.

Question

Independently of how taskiq-redis should handle the Redis timeout itself, is it intentional for an exception from broker.listen() to terminate the worker process?

Some broker/listener errors can be transient, such as:

• temporary network failures;
• backend connection resets;
• read timeouts;
• short backend outages.

It seems potentially useful for Taskiq to distinguish between:

1. an unrecoverable broker failure that should terminate the worker; and
2. a transient receive/listen failure where the receiver could retry, possibly with backoff.

If recovery from transient listen() failures is deliberately considered the broker implementation's responsibility, it would be useful to document that explicitly as part of the broker contract.

Environment from the original case

• Python: 3.14
• taskiq: 0.12.4
• taskiq-redis: 1.2.3
• redis-py: 8.0.1
• Server: Valkey 9.0.3

The Redis-specific reproduction and workaround are available in taskiq-python/taskiq-redis#127.