Resque Bundle Laravel Package

Getting Started

Read this as a Symfony 2 bundle, not a Laravel package. There is no service provider, no facade, no config/ publishing, and no queue driver adapter. composer require theviralab/resque-bundle will succeed inside a Laravel app, but the bundle class will never boot. If your goal is "use this in Laravel," the first step is actually reading its composer.json require section to find the underlying resque client (most likely chrisboulton/php-resque) and depending on that directly instead.

Where to look first, in this order:

1. README — for the config key alias and the console commands it registers.
2. DependencyInjection/ — the extension and Configuration.php tell you exactly which options exist (Redis host/port/database, queue names, worker defaults). This is the contract, more reliable than the docs.
3. Command/ — the worker and enqueue commands. These tell you how the package expects processes to be launched.
4. Resources/config/services.yml — the service IDs you'd inject.
5. Job/ or wherever perform() classes live — the shape of a job.

Minimal steps in the target environment (Symfony 2):

// app/AppKernel.php
$bundles = [ /* ... */ new TheViralab\ResqueBundle\ResqueBundle() ];

Then add a config block under the bundle alias in config.yml pointing at Redis, and start a worker via app/console.

Your first use case should be one idempotent, low-risk job — a welcome email, a thumbnail resize, a webhook retry. Enqueue it, watch it flow from Redis into a worker, confirm the failed queue stays empty. If you can't complete that loop in an hour, stop: the integration debt already exceeds the value.

Implementation Patterns

Job classes are plain PHP objects with a perform() method, dispatched by fully-qualified class name. The standard php-resque shape:

class SendWelcomeEmail
{
    public function perform()
    {
        $userId = $this->args['user_id'];
        // re-hydrate, then act
    }
}

The bundle's value-add is wrapping Resque::enqueue() behind a service or console command rather than raw static calls. Keep it that way:

• Inject the producer service, not the static. One-liner enqueue calls in controllers/commands; all domain logic inside perform(). This is the only way the job classes stay testable.
• Pass scalars or IDs, never entities. Arrays of primitives only. Re-fetch inside the worker.
• One worker process per queue, supervised. Supervisor or systemd, numprocs matching your concurrency needs. Never enqueue inline "just for now" in production — you'll forget.
• Idempotency by default. Resque is at-least-once. Guard every side effect with a unique key in Redis or a processed_at flag in the DB.
• Fan-out via chained jobs. If the bundle exposes the underlying client, use enqueue inside perform() for follow-up work rather than doing five things in one job.

Gotchas and Tips

• This is a dead dependency. Zero stars, zero dependents, no issue traffic, and Symfony 2 is EOL. Treat it as a reference implementation to read — a working example of how someone wired php-resque into a DI container — not something to ship. Fork it into your own namespace if you take anything from it.
• The Laravel mismatch is fundamental. Symfony Bundle classes and Laravel service providers do not interoperate. There's no published config, no facade, no Queue::push() integration. You'd be re-implementing the bundle from scratch around the underlying library.
• Worker autoloading is the #1 silent failure. The job class string you enqueue must match exactly — namespace case, no leading backslash inconsistency — and be autoloadable from the worker's environment. Symptom: jobs pile up in resque:queue:* forever while the worker logs an unresolvable class. Verify by running a worker in the foreground first.
• Forking corrupts inherited connections. php-resque workers fork per job. Any Redis or DB connection opened in the parent is shared with the child and will produce garbage responses. Reconnect at the top of every perform(). This is not optional and not obvious from the code.
• Long-running workers leak memory. Set a job cap (--count=N or equivalent) and let the supervisor restart the process. Don't trust PHP's GC in a fork loop.
• Debug by inspecting Redis directly. redis-cli keys 'resque:*', then lrange resque:queue:default 0 -1 and lrange resque:failed 0 -1. Unless the bundle happens to wire up resque-web (unlikely), you're reading failures by hand.
• Check the DI extension's config tree before anything else. If a Redis option isn't there, the bundle doesn't support it, and you'll be patching rather than configuring.
• The sane alternative: depend on chrisboulton/php-resque yourself with a thin provider, or — for Laravel teams — use the native Redis queue with Horizon. You get retries, metrics, a dashboard, and an API that gets security patches. This bundle offers none of that.