- How do I install dejwcake/laravel-queue-rabbitmq in a Laravel app?
- Install it with Composer using composer require dejwcake/laravel-queue-rabbitmq, then add a RabbitMQ connection entry to config/queue.php. The package requires PHP ^8.1, so confirm your runtime and Laravel version before upgrading. After installing, point your default or named queue connection at the RabbitMQ driver and run a worker to verify connectivity.
- Which Laravel and PHP versions does this RabbitMQ queue driver support?
- The package requires PHP ^8.1 and is aligned with supported Laravel releases, with 15.1.0 specifically addressing Laravel 13 worker internals. The release targets signature changes across Laravel 13.18+, 13.31+, and earlier 13.x boundary versions, and CI exercises those boundary versions. If you are on non-Laravel-13 deployments, verify behavior in staging separately even though the constraints suggest broad support.
- How do I configure the RabbitMQ connection in config/queue.php?
- Configuration lives in queue.php, where you define a connection using the package's RabbitMQ driver along with exchanges, routing, delays, and connection details. Set that connection as your default queue connection or select it explicitly when dispatching jobs. Because exchange declarations now wait for RabbitMQ confirmation at startup, misconfigured or missing exchanges surface immediately rather than silently later.
- Does this package work with Laravel Horizon?
- Yes, the package explicitly supports Laravel Horizon, so Horizon can manage and monitor workers consuming from RabbitMQ. You still configure the RabbitMQ connection in queue.php and define worker options in your Horizon configuration. Note that Horizon and Supervisor both react to process exit behavior, so review restart rules after upgrading to 15.1.0.
- How do I run a RabbitMQ worker for Laravel queues?
- Start a worker with the rabbitmq:consume command instead of the default queue:work command, typically under Supervisor, systemd, or Kubernetes. Options such as --max-jobs, --stop-when-empty, --stop-when-empty-for, and time and memory limits are respected on affected Laravel versions after 15.1.0. Exercise these flags in staging before rolling the worker definition out to production.
- Why did rabbitmq:consume start exiting with non-zero codes after upgrading?
- Version 15.1.0 changed worker exit codes to reflect the actual stop reason instead of always returning 0. That means memory-limit exits, time limits, and other stop conditions now produce distinct codes such as 12 for memory limits. Update your Supervisor, systemd, or Kubernetes restart policies and alert thresholds so these codes do not trigger restart loops or alert storms.
- How do I dispatch delayed jobs over RabbitMQ in Laravel?
- Delays are handled through the package's queue configuration, so delayed jobs are published to RabbitMQ with the appropriate delay rather than being simulated in the application. Configure the delay behavior on your RabbitMQ connection in queue.php, then dispatch jobs using Laravel's standard delay methods. Test the timing in staging, since behavior depends on your exchange and queue setup.
- Why is my Consumer::pauseWorker() override no longer being called?
- In 15.1.0 the package no longer calls Consumer::pauseWorker() overrides, so any custom logic placed there will silently stop running. Paused consumers now exit on SIGTERM, queue restart, time limits, or memory limits instead of waiting to be resumed. Refactor that logic into a supported extension point or a supervisor-level handler before upgrading.
- How should I test this RabbitMQ queue driver before deploying?
- Run your application test suite after updating Composer constraints, then exercise rabbitmq:consume in staging with --max-jobs, --stop-when-empty, time limits, memory limits, SIGUSR2, and SIGTERM. The package itself ships functional end-to-end tests covering rabbitmq:consume plus PHP QA tooling such as Pint, phpstan, phpmd, and compatibility checks. Validate stop and restart behavior under your actual process manager, then canary deploy queue workers and watch restart counts and alert noise.
- Is this package maintained, and what are the alternatives?
- Maintenance signals are positive: functional end-to-end tests now cover the consumer command, CI tests Laravel boundary versions, and static analysis and style tooling are part of the pipeline. If you need a different transport, Laravel's built-in database, Redis, and SQS drivers are the standard alternatives, or you can use other community AMQP drivers. For RabbitMQ specifically, this package is a drop-in replacement for the default queue driver and keeps Horizon support.