[GH-ISSUE #351] [FEATURE REQUEST] Rethink the semantics of "Paused" queue #151

New issue

Open

opened 2026-03-02 05:19:10 +03:00 by kerem · 0 comments

kerem commented

2026-03-02 05:19:10 +03:00

Owner

Originally created by @hibiken on GitHub (Nov 17, 2021).
Original GitHub issue: https://github.com/hibiken/asynq/issues/351

Originally assigned to: @hibiken on GitHub.

With current implementation (v0.19.0), the semantics of "paused" queue is such that no workers are going to pick up tasks from the queue (i.e. we stop tasks from the queue to be handled while the queue is paused).

This may be sufficient to stop bad task handlers to execute to bring down the error rate. However, we may also want to support "pausing the queue" from the client side, so that we block all clients to enqueue tasks to the queue. A possible use case would be to drain the queue, we want to stop all clients to send tasks to a queue so that we can let handlers to execute all the backlog tasks.

We should add a separate operation for this use case.

Originally created by @hibiken on GitHub (Nov 17, 2021). Original GitHub issue: https://github.com/hibiken/asynq/issues/351 Originally assigned to: @hibiken on GitHub. With current implementation (v0.19.0), the semantics of "paused" queue is such that no workers are going to pick up tasks from the queue (i.e. we stop tasks from the queue to be handled while the queue is paused). This may be sufficient to stop bad task handlers to execute to bring down the error rate. However, we may also want to support "pausing the queue" from the client side, so that we block all clients to enqueue tasks to the queue. A possible use case would be to drain the queue, we want to stop all clients to send tasks to a queue so that we can let handlers to execute all the backlog tasks. We should add a separate operation for this use case.