Front-of-queue dispatching

Send an urgent job to the head of the queue so a worker picks it up next.

Front-of-queue dispatching prepends a job to the head of its Redis queue instead of appending it to the tail, so it is the next job a worker picks up. Add the InteractsWithFrontOfQueue trait to the job and call onFront() on dispatch. It buys ad-hoc priority for one urgent job without standing up a dedicated high-priority queue — and it breaks FIFO, which has consequences worth reading to the end for.

Usage#

Add the InteractsWithFrontOfQueue trait to the job, then call onFront() on the pending dispatch:

use Illuminate\Bus\Queueable;
use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Foundation\Bus\Dispatchable;
use Laravel\Horizon\InteractsWithFrontOfQueue;

class ProcessPodcast implements ShouldQueue
{
    use Dispatchable, InteractsWithFrontOfQueue, Queueable;

    // ...
}

// Jump to the front of the queue:
ProcessPodcast::dispatch($podcast)->onFront();

// Composes with the usual dispatch options:
ProcessPodcast::dispatch($podcast)->onFront()->onQueue('media');

When you are working with raw payloads, reach for the underlying queue method directly:

Queue::connection('redis')->pushRawOnFront($payload, 'media');

How it works#

A Redis queue is a list. Dispatching normally RPUSHes the payload onto the tail while workers LPOP from the head. onFront() flags the job, and Skyline's RedisQueue then LPUSHes it onto the head instead — so the next worker to pop takes it.

A front-pushed job still fires the usual JobPending and JobPushed events, so it appears on the dashboard and in metrics exactly like any other job.

Caveats#

Front-of-queue dispatch is a deliberate escape hatch. It buys latency for one job by breaking a property the rest of the system quietly assumes.

• Immediate dispatch only. Delayed jobs (->delay(...)) live in a sorted set ordered by their available-at time, so onFront() has no effect on them until they migrate onto the ready queue.
• It breaks FIFO ordering. Prepending is a priority side-channel. For stable, configuration-driven priorities prefer several queues served in order — or weighted queues.
• It skews wait-time metrics. Skyline estimates a queue's actual wait time from the job at the head of the list, on the assumption that it is the oldest. A freshly prepended job sits at the head, so actual wait time and long-wait notifications can under-report the true backlog on queues that receive front-pushed jobs. There is no cheap fix for this once FIFO is broken.
• Redis only. The behaviour relies on Redis list semantics and does not apply to the sync or database queue drivers.