J Queue Bundle Laravel Package

Getting Started

First, a reality check. an1zhegorodov/j-queue-bundle is a Symfony2 bundle, not a Laravel package. It has no stars, no dependents, and no CI signal. That doesn't make it useless — it makes it a read-the-source dependency, not a drop-in one. If you're a Laravel developer, the honest first step is deciding whether you actually need this at all: Laravel already ships Queue, Bus, and Horizon, and unless you're maintaining a legacy Symfony 2.x application (or porting one), you should stop here and use the framework you already have.

If you are on a legacy Symfony 2.3–2.7 codebase:

1. Check it installs at all. composer require an1zhegorodov/j-queue-bundle — if it's not on Packagist under that name, fall back to a VCS repository entry pointing at the GitHub URL. Read the resulting composer.json require block; the PHP constraint is the make-or-break detail (expect ~5.3/~5.4 era, which will fight any modern dependency set).
2. Register the bundle in app/AppKernel.php inside registerBundles().
3. Open three files before writing any code: the bundle's composer.json (for the real PSR-4 namespace — the vendor name an1zhegorodov and the repo owner mintobit differ, so don't guess it), the DependencyInjection/*Extension.php (for config keys), and Resources/config/services.yml (for the service IDs you'll inject). Those three tell you more than any missing README will.

First use case: the smallest thing that proves the round trip — push one job payload from a controller/service, then pop it from a console command run manually. Don't wire it to cron or Supervisor until you've seen a payload go in and come out intact.

Implementation Patterns

Keep the producer/consumer split strict. Producers should only serialize a payload and hand it to the queue service; consumers should only deserialize and dispatch. Mixing the two in one class is how you end up unable to test either.

Inject the service, never instantiate. The bundle's value is its DI wiring. Get the queue service by ID from the container ($container->get('...') — confirm the ID in services.yml, don't assume) and type-hint it in your own services so it's swappable and mockable.

Design payloads as dumb data. Use scalars and arrays rather than serialized domain objects — PHP object serialization across a queue boundary is a versioning trap and a security smell on deserialize. A common shape that ages well:

['type' => 'send_welcome_email', 'args' => ['userId' => 42], 'id' => $correlationId]

Then keep a type => callable/service-id map in your application code, not inside the bundle. That map is your extension point when the bundle inevitably can't do what you need.

Worker loop with the boring safety rails. Whatever the API looks like, the consuming command will be a loop. Give it: a sleep on empty pop (don't busy-spin), a memory_get_usage() guard that exits cleanly so Supervisor can restart it, and a max-jobs counter. If the bundle's pop is blocking, still cap runtime.

Make every handler idempotent. You have no visibility into this bundle's acknowledgement semantics, so assume at-least-once delivery: a job may run twice after a crash. Handlers should check "already done?" before acting.

Bridge, don't marry. If you're straddling a Laravel and a Symfony app, put the queue behind your own interface (push(array $payload)), back it with this bundle on the Symfony side and Queue::push on the Laravel side. Migration later becomes a one-class change.

Testing: don't test through the queue. Unit-test the handler by calling it directly with a payload array; integration-test by pushing and popping synchronously in a test case.

Gotchas and Tips

• EOL on both axes. Symfony2 is long dead and the PHP constraint is likely 5.x-only. On PHP 8 this will either refuse to install or install and emit deprecations. Vet it in a throwaway container before it touches a real app.
• The namespace is not obvious. Vendor an1zhegorodov, repo mintobit. Read the autoload mapping in composer.json before writing a single use statement; guessing wastes an hour.
• Unknown persistence backend. File-based? Database table? Beanstalkd? You cannot assume durability until you find the storage code. If it writes to a temp directory, "the queue" dies with the container — a fatal surprise in any multi-host setup.
• Zero dependents is a maintenance signal. Nothing forces a fix when PHP or Symfony moves. The realistic plan is: fork it, vendor it (composer.json repositories with a VCS entry pinned to a commit), or replace it. Budget for the replacement up front.
• Debugging is on you. Since there's no tooling, log on both sides of the boundary with a shared correlation ID — one line at push, one at pop, one at handler completion. That triad answers 90% of "where did the job go?"
• Inspect the container when wiring fails. app/console container:debug (or debug:container) lists the real service IDs and their arguments; it's the fastest way to discover a service the bundle registers but doesn't document.
• Extension points to reach for first: (1) override a service definition in your app's config.yml/services.yml, (2) write a compiler pass to decorate the queue service, (3) setter-inject your own storage/serializer if the bundle exposes one. If none of those work cleanly, that's your cue to migrate — to Symfony Messenger if you stay on Symfony, or to Laravel's database/redis queue driver if you're heading that way.