Resque Bundle Laravel Package

Getting Started

Reality check first: instasent/resque-bundle is a Symfony2 bundle, not a Laravel package. It has no service provider, no facade, and no Laravel config integration. As a Laravel developer, you will almost never install this bundle directly. What you actually want is the underlying library it wraps — php-resque (or a maintained fork) — plus a small Laravel service provider of your own.

New in v0.2.5: a single fix — "Fixed key for retry_strategy". This is a patch that corrects the config key name used when wiring a retry strategy into the bundle's configuration. It confirms the bundle has (and intends to support) a retry_strategy config option, but it changes nothing about the framework story: still Symfony, still no Laravel integration. It does mean the repo is not strictly abandoned — a release landed after a long quiet period — but one key-name fix is not a maintenance commitment.

If you are evaluating this repo for architectural ideas:

1. Read README.md for the bundle's config keys and console commands — pay attention to the retry_strategy node, whose key name changed in v0.2.5.
2. Look at DependencyInjection/ and Resources/config/services.yml to see how the Resque service and worker command are wired, and how retry_strategy is passed through to the underlying library.
3. Look at the job interface/base class and the resque:worker / enqueue command implementation.
4. Check composer.json for the php-resque version it pins — that tells you the real compatibility story. Retry behaviour lives in that pin (a fork/plugin with retry support), not in php-resque core.

First practical use case in a Laravel app: install a php-resque fork, register a singleton that wraps Resque::enqueue(), and run a worker under Supervisor. The bundle's patterns (a thin service around enqueue + a long-running worker command) map cleanly onto a Laravel service provider and an Artisan command.

Implementation Patterns

Enqueueing from Laravel

• Create job classes with a perform() method matching php-resque's contract.
• Register a Resque singleton in a service provider that reads Redis host/port/database from config/database.php.
• Enqueue with Resque::enqueue('queue_name', JobClass::class, $args).
• Keep $args small, JSON-serializable, and scalar. Pass IDs, not Eloquent models.

Worker process

• Wrap the php-resque worker loop in an Artisan command (resque:work) or run the upstream bin/resque script directly.
• Run workers as separate processes from the web app, supervised by Supervisor or systemd.
• Use environment variables for QUEUE, INTERVAL, COUNT, and VERBOSE, mirroring php-resque conventions.

Integration tips

• Share the same Redis instance/prefix between the Laravel app and the worker so enqueue and dequeue see the same keys (resque:queue:<name>, resque:workers, resque:failed).
• Namespace queue names per environment (prod:emails, staging:emails) to avoid cross-environment job leakage.
• Make jobs idempotent. Resque core has at-least-once semantics and no built-in retry/backoff like Laravel's queue — retries are a function of the strategy you configure, not of the transport.
• Deploy job class code before enqueueing jobs that reference it — workers resolve class names at runtime.
• If you need monitoring, the classic resque-web UI is Ruby-based; otherwise build a small Laravel dashboard reading Redis keys.

Modelling the bundle's retry config in Laravel

• If you copy the bundle's approach, a "retry strategy" is a small value object (max attempts, delay/backoff, retry-on-failure predicate) injected into the worker, not a queue feature. v0.2.5's fix is essentially a reminder that this config key must be threaded through explicitly — a misnamed key silently disables retries.
• In Laravel, prefer retry_after, tries, and backoff on the native Redis queue job, or Horizon for the whole story, rather than re-implementing a strategy object on top of php-resque.

When the bundle itself is relevant

• Only if you maintain a Symfony2/3 service alongside a Laravel service and want one shared job infrastructure.
• Use it as a reference implementation for DI wiring, config tree structure, retry-strategy plumbing, and command ergonomics, then replicate those ideas in Laravel.

Alternative pattern — don't use Resque at all

• Laravel's native queue with the Redis driver (plus Horizon) gives you retries, backoff, failed-job tables, metrics, and a UI out of the box.
• Choose php-resque only when you need cross-language workers, existing Resque tooling, or Redis-only infrastructure shared with Ruby/PHP services.

Gotchas and Tips

• Framework mismatch is the biggest gotcha. This bundle cannot be dropped into Laravel. You will spend more time stripping Symfony assumptions than using the package.
• Maintenance signal is weak but not dead. Four stars, zero dependents, a long gap ending in v0.2.5 — a one-line config key fix. Treat it as lightly maintained at best. Still audit the pinned php-resque version for PHP 8 compatibility; older php-resque releases have issues with PHP 8 type handling and deprecated APIs. Prefer a maintained fork.
• The v0.2.5 fix is a silent-failure trap. A wrong retry_strategy key means your retry config was previously ignored without error. If you copy config from older docs or from a pre-v0.2.5 README, you may be configuring a key the container never reads. Verify the exact key in DependencyInjection/Configuration.php against your config; do not trust blog posts or cached READMEs.
• "Retry strategy" is not the same as queue retries. The bundle passes a strategy object down; php-resque core has no backoff scheduler. Failed jobs land in resque:failed and stay there unless your strategy or a failure backend re-enqueues them. Do not assume Laravel-queue-like semantics.
• Serialization traps. Non-scalar args, closures, or objects with resources will fail at enqueue time or silently break the worker. Validate payloads before enqueueing.
• Worker memory growth. Long-running PHP workers leak memory. Set COUNT or restart workers periodically via Supervisor. Watch RSS in production.
• Graceful shutdown. Ensure your worker handles SIGTERM/SIGINT so in-flight jobs finish, and that retries aren't double-counted across a restart. Configure Supervisor with stopsignal=TERM and a sensible stopwaitsecs.
• Debugging. Run workers with VERBOSE=1 and VVERBOSE=1 to see job pickup and failures. Inspect Redis directly: LLEN resque:queue:<name>, SMEMBERS resque:workers, LRANGE resque:failed 0 -1. When retries "don't work", check the container's resolved config first — that was exactly the v0.2.5 bug class.
• Config quirks. The bundle exposes Redis connection and queue settings through Symfony's config tree (instasent_resque:), which does not map to Laravel's config/*.php conventions. If you port it, keep connection settings in config/database.php, keep retry settings in a dedicated config/queue.php block, and inject via the container.
• Extension points worth copying. php-resque's hooks (beforeEnqueue, afterEnqueue, beforePerform, afterPerform, onFailure) are the right place for logging, metrics, idempotency checks, and retry bookkeeping. Wrap them in a Laravel service provider rather than forking the library.
• Operational risk. One patch release after a multi-year gap is not a support guarantee. Assume no upstream fixes for the next issue you hit; budget for vendoring or forking if you adopt this stack.