- Is rsqueue/rsqueue-bundle compatible with Laravel?
- No. rsqueue/rsqueue-bundle is a Symfony2 bundle built around a dependency-injection extension, a semantic configuration tree, and Symfony console commands, and Laravel has none of those surfaces. Laravel has no bundle concept, no AppKernel, and a different container, config loader, and console kernel, so the fit against a Laravel codebase is effectively zero. There is no service provider, queue connector, or config file that Laravel could load.
- Can I install rsqueue-bundle in a Laravel project with Composer?
- A direct Composer require into a Laravel app is expected to fail on Symfony 2 component constraints, and even if it resolved it would not boot. The package ships no Laravel service provider, facade, or queue driver, so there is nothing for the framework to register. Treat it as a reference implementation to read, not a dependency to install.
- Does rsqueue-bundle support Laravel 10 or Laravel 11?
- No. The bundle targets the Symfony 2.x lifecycle from 2.3 LTS through 2.8, which reached end of life in November 2018, the same period as the package's last release. There has been no PHP 8.x compatibility work and no modernization for newer framework conventions. It should not be considered for any current Laravel version.
- What is the Laravel equivalent of rsqueue-bundle?
- Laravel's built-in Redis queue driver is the direct functional equivalent, and Laravel Horizon adds the observability this bundle lacks. Outside Laravel, the comparable choices are Symfony Messenger with a Redis transport, Redis Streams consumer groups, or a managed broker such as SQS. Any of these gives you retries, delayed jobs, failed-job storage, and an actively maintained security posture.
- Is rsqueue-bundle abandoned or still maintained?
- It is effectively abandoned. There has been no release since 2018-10-08, no visible maintainer activity, and no dependents, which means no security patches and no PHP 8.x or Redis 6/7 validation. The technical risk is high and concentrated in sustainment rather than correctness.
- Does rsqueue-bundle support retries, delayed jobs, and failed-job handling?
- Based on the technical evaluation, there is no evidence of a visibility timeout, acknowledgement step, dead-letter queue, retry or backoff policy, or delayed-job support. It appears to be a classic list-based queue using plain blocking pops. Confirm this yourself before relying on any delivery or retry semantics.
- What delivery guarantee does rsqueue-bundle provide?
- Classic list-based queues using plain BRPOP give at-most-once delivery, so a worker that crashes mid-job loses the payload with no requeue. The single most important thing to verify is whether the consumer uses BRPOP, BRPOPLPUSH, or a Lua script, because that determines whether the queue is at-most-once or at-least-once. Do not assume reliable pop without checking the code.
- Does rsqueue-bundle run on PHP 8.1 or later?
- Unlikely without changes. The package is Symfony 2 era with PHP 5.x-era type hints and conventions, and no PHP 8.x compatibility work has been published. Check the declared PHP and Symfony constraints in composer.json, and expect the code to need modernization before it runs on PHP 8.1 or newer.
- Is rsqueue-bundle safe to run in production?
- The sustainment risk is high. There are no security patches, no metrics, no structured job-failure events, and no introspection beyond LLEN, so operating it means running blind and paying a real on-call cost. Symfony 2 conventions will also resist modernization and confuse engineers used to Symfony 5/6 or Laravel.
- How do I migrate from rsqueue-bundle to Laravel's Redis queue driver?
- Use the repository as a reference implementation rather than a dependency. Read the Redis key schema, the blocking-pop loop, and the payload serialization format, then reimplement roughly 200 to 400 lines as a native Laravel queue driver or small internal package. Note that PHP serialize() payloads are brittle to class renames and unsafe across languages, so prefer JSON when you rewrite it, and use Laravel jobs with retries, backoff, and the failed_jobs table for reliability.