I have had something like this for years on a project to skip jobs after reaching an API rate limit to avoid attempting several jobs in a row.

It also allows having a worker working on more than one queue while the other one is paused/blocked (in my implementation I call it blocked).

Locally I have a custom queue driver that extends from theDatabaseQueue class and just overrides thepop method to returnnull while the queue is blocked.

And a job middleware to block/pause the queue when a 429 response is caught.

It will be great to have this in the framework.

Also, it is a much more generic solution than mine.

Thanks a lot!

I think I would want the ability to pause on both connection and queue with syntax similar to:https://laravel.com/docs/12.x/queues#monitoring-your-queues

php artisan queue:pause redis:default

vadimonus

Hi Taylor,

Thank you for the feedback! I've updated the implementation to support theconnection:queue syntax exactly as you suggested.

Changes made:

✅ Commands now acceptconnection:queue format (e.g.,redis:default)
✅ Follows the same pattern asqueue:monitor command
✅ Defaults to the default connection if only queue name is provided

Examples:

php artisan queue:pause redis:defaultphp artisan queue:pause database:emails --ttl=3600php artisan queue:resume redis:default

The implementation uses aparseQueue() method similar toMonitorCommand to handle the parsing. All tests are passing with full connection isolation.

Interesting idea, but solution has flaws

Hi vadimonus,

Thank you for the detailed code review! I've addressed all three issues you identified:

1. Race Condition ✅

You were absolutely right about the non-atomic operations. I've implemented proper locking usingcache->lock():

$lock =$cache->lock('queue_paused_list_lock',10);try {$lock->block(5);$pausedQueues =$this->getPausedQueues();// ... modify list atomically ...$this->storePausedQueuesList($pausedQueues);}finally {$lock->release();}

This ensures atomic read-modify-write operations and prevents the concurrent modification issue you described.

2. TTL Default Value ✅

Changed from 1 day tonull (indefinite pause) as you suggested:

publicfunctionpause($connection,$queue,$ttl =null){if ($ttl ===null) {$cache->forever("queue_paused:{$connection}:{$queue}",true);    }else {$cache->put("queue_paused:{$connection}:{$queue}",true,$ttl);    }}

The--ttl option is now optional, and developers can specify custom TTL when needed.

3. Connection Name ✅

All methods now include connection name in the cache key:

// Cache key format: queue_paused:{connection}:{queue}queue_paused:redis:defaultqueue_paused:database:emails

This ensures pausingredis:default doesn't affectdatabase:default. The pause list also stores queues inconnection:queue format.

Test Coverage:
14 tests, 40 assertions - all passing ✅

Thank you again for the thorough review!

@yousefkadah , i still do not undertand use cases , where listing of paused queues can bee needed. The declared problem is that's no ability to pause certain queue. This problem is solved well without listing currrently paused queues.

Take a look at mentionned earliermonitor command. It works only with provided as argument list of queues. If someday you decide to extand this command to show if queue it's paused or not,Queue::isQueuePaused would be enougt, and you will not needgetPausedQueues method for it.

You're using cache locks to prevent race condition. Currently Queues does not depends on cache locks feature. Not all cache drivers (do not forget for custom ones) can provide locking feature. Pausing will fail with such drivers.
So feature of listing paused queues gives more questions, than profits. You may allways introduce this later as separate feature, as well as showing paused queues in monitor command.

Let's wait for@taylorotwell , only his opinion is significant here

Simplified this a bit to remove the listing stuff and blocking to just get a simpler version of the feature in now while I think about how I want to expose and manage the list.