Queue Bundle Laravel Package

Getting Started

Reality check first: this is a Symfony bundle (last release 2017, ~31 stars), not a Laravel package. There is no service provider, facade, or config/queue.php integration. If you are on Laravel, the honest day-one move is to use illuminate/queue with Redis/SQS and treat this bundle only as a reference for interface design. If you are working in a legacy Symfony 2/3 app (the only place where it fits), proceed as below.

Minimal steps in Symfony:

composer require symfony-bundles/queue-bundle

• Register the bundle in app/AppKernel.php (or bundles.php on Symfony 4, though the package predates that convention) under new SymfonyBundles\QueueBundle\QueueBundle().
• Open DependencyInjection/Configuration.php before writing any config. That file is the authoritative documentation for the driver tree and available options — the README is thin and the 2017-era docs assume a specific Symfony version.
• Check composer.json for the PHP and Symfony constraints. You will likely need --ignore-platform-reqs on modern PHP; expect the bundle to be untestable on PHP 8 without patches.
• Confirm which transport extensions are installed: ext-amqp for AMQP drivers, ext-redis, etc. Most "class not found" errors at boot are missing extensions, not missing config.

First use case: define one queue in config, inject the producer service into a controller, push a message, then run the bundle's consumer command in a second terminal and watch the message round-trip. Get that working before wiring anything into real domain code.

Implementation Patterns

• Config-driven driver selection. The bundle's value is a common producer/consumer interface over multiple transports. Keep the driver choice in your bundle config (per environment) so test/staging/prod can differ without code changes.
• Producer injection. Inject the queue service (or a thin domain-specific wrapper around it) rather than resolving it from the container inside your code. Wrap it in a JobDispatcher class of your own so swapping the bundle out later is a one-file change.
• Worker command loop. Consumer logic lives in the bundle's console command. Run it under a process supervisor (supervisord/systemd), never as a one-shot in a request cycle. Set a time limit and restart policy.
• Message contract. Define your own message DTOs and serialize them explicitly (JSON is the safe choice). Do not rely on PHP serialize() across versions — this bundle was written when that was common and it will bite you.
• Laravel bridge (if you must). Create a small service provider that binds the bundle's queue service into the container, translating Laravel jobs into the bundle's message shape, and run the bundle's consumer as a custom Artisan command. This is glue code you own forever; document it.
• Testing. Point the config at the lightest available driver (or a stub implementing the bundle's queue interface) in config_test.yml so functional tests don't need a broker.

Gotchas and Tips

• Abandoned since 2017. No PHP 8 support, no security fixes, no Symfony 5/6 compatibility. Treat it as frozen third-party legacy code and pin the exact version in composer.lock.
• Not a Laravel package. Forcing it into Laravel means fighting two dependency trees (Symfony components vs. Illuminate). If a package resolution conflict appears, stop — the ROI is not there.
• Long-running workers leak memory. Old queue libraries rarely clear the entity manager or reset services between jobs. Restart workers every N jobs (--max-jobs-style flags may not exist; do it via supervisor).
• Persistent broker connections go stale. AMQP connections die silently after idle periods or broker restarts. Add reconnect/retry logic in your wrapper, not in the bundle.
• Config tree mismatches. A wrong key in the driver config often fails at container compile time with a vague error. Run bin/console cache:clear (or debug:container) to surface the real exception.
• No visibility into failures. There is no dead-letter or failed-job table out of the box. Build your own: catch exceptions in the consumer, log the payload, and push to a dead queue.
• Extension points. The cleanest extension is a custom class implementing the bundle's queue/message interface, registered by overriding the service definition in your app's services.yml. That lets you keep the bundle's wiring while swapping the transport.
• Debugging tip. When a message "disappears," check the broker directly (rabbitmqctl list_queues, redis-cli KEYS) before touching application code — the bundle often swallows transport errors into a generic exception.