You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I would like to check if it is expected behavior or if there is a way to change it.
I noticed if I connect a worker/consumer to the default queue that does not have implemented a handler for a certain pattern/task type, it still tries to consume the task and then puts back in queue incrementing the retry count and eventually exhaust all the retries.
Is expected that all workers connected to asynq on certain Redis instance, should be able to handle all types of tasks?
There might be some cases where some workers might interested in some kind of tasks and other in different ones. What should be the pattern to implement such use case? Different Redis instance? Different DB? Different queue names?
The text was updated successfully, but these errors were encountered:
Before I run that code to investigate further, could you debug with the inspector/CLI? This kind of issue usually comes about because of incorrect use of the library (based on the previous issues reporting something similar).
Hello,
I would like to check if it is expected behavior or if there is a way to change it.
I noticed if I connect a worker/consumer to the default queue that does not have implemented a handler for a certain pattern/task type, it still tries to consume the task and then puts back in queue incrementing the retry count and eventually exhaust all the retries.
Is expected that all workers connected to asynq on certain Redis instance, should be able to handle all types of tasks?
There might be some cases where some workers might interested in some kind of tasks and other in different ones. What should be the pattern to implement such use case? Different Redis instance? Different DB? Different queue names?
The text was updated successfully, but these errors were encountered: