- Can I use pixelplan/messenger-job-batch-bundle in a Laravel application?
- No. Despite being listed alongside Laravel packages, this is a Symfony bundle built on symfony/messenger and registered through the Symfony bundle and DI system, not a Laravel package with a service provider, facade, or config publish. It has no integration with Illuminate\Bus\Batch, so installing it in Laravel means manually bootstrapping a bundle kernel-less component alongside your existing queue worker. For Laravel the practical answer is to use the native Bus::batch() API instead.
- What does Bus::batch() in Laravel already provide compared to this bundle?
- Laravel ships first-party job batching with then, catch, and finally callbacks, allowFailures(), and a job_batches table that is already migrated in the framework. That covers group dispatch, progress tracking, and completion signalling without any third-party dependency. The Symfony bundle offers roughly the same concept for Messenger, so adopting it in Laravel would mean running two competing async models on top of each other.
- How do I install and register this bundle in a Symfony project?
- Installation is a standard composer require pixelplan/messenger-job-batch-bundle, followed by registering the bundle in config/bundles.php like any other Symfony bundle. After that you need to stamp each message in a batch at dispatch time, provision the state store, and wire your completion handlers. The composer step is quick; the surrounding integration work is where the real effort sits.
- Where does the bundle store batch state, and does it survive worker restarts?
- That is the single most important thing to verify in source, because the bundle requires a shared, durable store such as a Doctrine table or Redis that is visible to every worker host. Any implementation defaulting to cache.app, APCu, or the array adapter will silently produce batches that never complete in a multi-host deployment. Check whether a schema migration or Doctrine entity ships with the package and how retention and purge are handled.
- How does the bundle count completed messages without double-counting on retries?
- Completion tracking is the classic distributed-counter problem, and the locking and idempotency strategy is what you should review first. Look for an atomic UPDATE that increments a done counter with a compare-and-set, plus a unique constraint that makes counting idempotent when a message is redelivered. Read-modify-write counters, or counting without a dedupe key, will either finish a batch early or leave it hanging forever under concurrency and retries.
- What happens to a batch when one of its messages fails permanently?
- This is not documented in the material available, so confirm it in code before relying on it. Specifically, check the behaviour after WorkerMessageFailedEvent fires past the retry limit, and whether a RecoverableMessageHandlingException leaves the batch pending. A batch that hangs in pending with no failure transition is worse than a loud error, so test this path explicitly.
- Does the bundle support batch-level catch and finally semantics, or only a success callback?
- The evaluation notes flag this as an open question rather than a confirmed feature, which suggests a single success callback is the documented path. If you need failure handling and guaranteed cleanup logic per batch, verify whether the package emits distinct finished, failed, and always-run signals. Without that, you end up rebuilding orchestration on top of the completion event anyway.
- Which PHP and Symfony versions does this package support?
- Targeting is Symfony 5.4, 6.x, and 7.x with Messenger already running in production, and PHP constraints should be read from composer.json. Confirm there is CI proving the version matrix before committing, since a package with no external contributors rarely has broad build coverage. Also verify that the listed release tag actually resolves and is installable on Packagist rather than being a metadata artifact.
- Is this bundle safe for production, and how much integration effort should I budget?
- Technical risk is high, concentrated in vendor stability and counter correctness. A realistic spike is two to four engineer-days to stamp messages, migrate the state store, wire handlers, and prove correctness under concurrency, plus roughly a week of soak testing before production. You also need a reconciliation or sweeper strategy for orphaned and stuck batches, since retries and redeliveries will eventually leave one behind.
- What are the maintenance and vendor risks, and are there alternatives?
- The repository shows zero stars, zero dependents, and a single maintainer with no external contributors, so assume no upstream fixes will arrive. The MIT licence and small surface area make forking a viable hedge, but you should budget for owning it. If your host application is Laravel, the alternative is simply Bus::batch(); if it is Symfony, weigh this against a thin in-house counter table tailored to your transport topology.