Resque Bundle Laravel Package

Getting Started

First, correct the framing: shonm/resque-bundle is a Symfony 2/3 bundle, not a Laravel package. There is no service provider to register, no Artisan command, and no config/queue.php connection to add. A Laravel developer "leverages" this package in exactly two situations: (a) you inherit a legacy Symfony app that already runs it, and need to keep jobs flowing while you plan an exit; or (b) you're sizing a migration and need to understand what the Resque model does. For new Laravel work, the answer is Laravel's native queue plus Horizon — the bundle contributes nothing to that path.

Where to look first (legacy Symfony app):

1. README.md and DependencyInjection/Configuration.php — the shonm_resque config block (Redis host/port/database, queue names, worker options).
2. Resources/config/services.yml — how Resque services are wired into the container.
3. Command/ — the resque:worker console command and its options.
4. Your app's job classes — anything with a perform() method is a Resque job.

Minimal bootstrap steps:

1. composer require shonm/resque-bundle (expect legacy Symfony/PHP constraints; check composer.json before anything else).
2. Register ShonM\ResqueBundle\ShonMResqueBundle in AppKernel.
3. Configure Redis and default queues under the shonm_resque key.
4. Start a worker: app/console resque:worker --queue=default.
5. Enqueue your first job:

// Job class — plain PHP, no framework hooks
class ThumbnailJob
{
    public function perform()
    {
        $path = $this->args['path'];
        // ... resize, write to storage ...
    }
}

// Enqueue from a controller or service
\Resque::enqueue('default', 'App\Job\ThumbnailJob', ['path' => $path]);

First practical use case: moving a slow write off the request cycle — image resizing, outbound email, PDF generation, third-party webhook fan-out. Something where a lost job is annoying but not catastrophic, because Resque does not guarantee delivery.

If you're actually on Laravel, the first use case maps to:

// app/Jobs/ThumbnailJob.php
class ThumbnailJob implements ShouldQueue
{
    use Dispatchable, InteractsWithQueue, Queueable, SerializesModels;

    public function __construct(public string $path) {}

    public function handle(): void
    {
        // ... resize ...
    }
}

// call site
ThumbnailJob::dispatch($path);
// worker: php artisan queue:work redis  (or Horizon)

That is the whole of the migration for a single job, and it's why the bundle has no place in a new Laravel codebase.

Implementation Patterns

Enqueue from the edge, execute off-request. The core pattern is unchanged from any queue system: keep call sites thin, pass scalars (paths, IDs, tokens) rather than hydrated models or fat DTOs, and let the job reload state by ID inside perform(). Resque payloads are PHP-serialized, so any object you pass becomes a frozen interface — see Gotchas.

Queue naming as a routing policy. Define a small fixed set of queues (critical, default, low) and run dedicated worker pools per queue with different concurrency. This is the Resque equivalent of Laravel's queue priorities, and it's the single cheapest reliability lever you have, since a busy low queue can't starve critical.

Worker supervision is your responsibility. resque:worker is a foreground process. Run it under supervisord or systemd with autorestart=true, one supervisor program per queue, N processes per program. Signal semantics follow php-resque: QUIT/TERM for graceful shutdown (finish current job), USR1 to pause before the next job, USR2 to resume. Deploy hooks should send a graceful stop and wait, otherwise you get zombie workers holding old code.

Wrap the job base class. Rather than scattering try/catch across job classes, subclass a project base job that logs start/end/duration, catches exceptions, and writes structured context (job class, args hash, queue, worker PID) to your logger. Resque gives you stdout and nothing else, so this wrapper is your observability layer.

Failure handling via a wrapper, not the core. Resque has a resque:failed list but no retry policy, backoff, or dead-letter semantics. Implement retries by re-enqueuing with an attempt counter in args, capped at N, and push exhausted jobs to your own dead-letter list plus an alert. If you need this in Laravel, retry_until, backoff(), and failed() hooks are built in and you should not rebuild them.

Interop pattern (the only strong reason to keep Resque). If Ruby workers share the same Redis, the wire format is the contract: a JSON or PHP-serialized envelope with class and args, pushed to the resque:queue:<name> list. Any adapter you write — in Laravel or elsewhere — must match that envelope exactly, and you should treat it as a versioned, frozen interface for the duration of the parallel run.

Dual-run during migration. Enqueue to both the legacy Resque queue and the new Laravel job behind a feature flag for a bounded window. Drain Resque workers to zero while comparing outputs on a sampled subset. This is the only safe sequencing when jobs have side effects, because it lets you prove parity before you delete the old path.

Config-as-code for queue topology. Keep queue names and worker counts in version control next to the supervisor config, not in a sysadmin's head. When you migrate to Horizon, that same topology becomes config/horizon.php nearly verbatim — supervisor-<queue> blocks with maxProcesses and balance: auto. Doing the inventory now pays for itself twice.

Gotchas and Tips

The repo is self-declared unmaintained. Twelve stars, zero dependents. Treat any adoption as a permanent fork: vendor it, pin the commit, and name an owner. There will be no security patch path and no one to escalate to.

Framework mismatch is the headline gotcha. Nothing here can be composer required into a Laravel app and used as intended — no bundle loader, no YAML container config, different console kernel and event contracts. If a catalog or recommendation surfaced this as a Laravel package, that's a data-quality bug worth filing.

pcntl and fork-per-job. Resque forks a child per job. That's unavailable under PHP-FPM, most managed container runtimes, and anything serverless. The classic symptom is a worker that starts and immediately exits with no useful error. Verify pcntl and POSIX signals are actually present in the target runtime before scoping any work.

No delivery guarantee. Classic Resque pops the job off Redis before executing. A worker killed mid-job loses it silently — no ack, no visibility timeout, no redelivery. If the requirement is at-least-once, this design fails it and no amount of wrapper code fixes the hole.

PHP-serialized payloads couple you to class shape. Renaming a job class or changing its properties breaks already-enqueued entries, and the failure surfaces later as workers dying on stale queue items. Mitigations: pass only scalars in args, drain the queue before deploying refactors, and keep job classes append-only. Laravel's JSON payloads remove this class of bug entirely.

Redis connections must be re-established after fork. If you inject a Redis client or a service that holds one, the forked child inherits a broken socket. Reconnect inside perform() or in an onFork-style hook, or you'll see intermittent, hard-to-reproduce connection errors under load.

Redis is a single point of failure with no graceful degradation. When Redis goes down, every worker stalls. Alert on queue depth and worker count, not just on job errors — otherwise the first signal you get is a user complaint about a stale page.

Poison jobs loop forever. No built-in retry cap or dead-letter queue. A job that throws will retry indefinitely unless your wrapper enforces a cap. Cap it.

Config quirks. Configuration lives under the shonm_resque key, and php-resque also honors environment variables (notably the Redis backend) that can silently override what you set in YAML. When a worker connects to the wrong database, check env vars before you touch the bundle config.

Debugging workflow. Run resque:worker in the foreground with verbose output when reproducing; inspect resque:queue:<name> (list), resque:stat:* (counters), and resque:failed (failures) directly with redis-cli. There is no UI and no metrics endpoint — bespoke redis-cli and log grepping are the whole toolkit.

Extension points are thin. The realistic ones are: a project base job class (logging, retries, idempotency keys), a custom failure handler/wrapper, and supervisor config for lifecycle. Do not expect plugin-style hooks; the php-resque plugin ecosystem is largely abandoned too.

Zombie workers after deploy. Without a supervisor-level reconciliation step, old workers keep running old code indefinitely. Make graceful stop plus verify-zero-workers a required deploy gate.

Bottom line for a Laravel developer. You will not pick this up to build something new. Use it as a reference for reading a legacy Symfony + Resque codebase, and as a checklist of exactly what Horizon gives you for free — supervision, retries, backoff, metrics, failed-job UI, and JSON payloads that don't break on refactor.