Messenger Job Batch Bundle Laravel Package

Product Decisions This Supports

• Feature feasibility for "notify me when it's done" UX. Bulk imports, CSV exports, catalog reindexing, mass emails, image/video transcoding, and report generation all need a reliable "batch complete" signal. This package provides that primitive for Symfony Messenger instead of a bespoke tracking table plus cron sweeper.
• Roadmap sequencing for async/bulk capabilities. If the roadmap has bulk operations or long-running workflows, batch-completion tracking is a prerequisite. Adopting it now unblocks later "fan-out/fan-in" features (dispatch N messages, run a finalizer when all finish) without re-architecting.
• Build vs. buy. The alternative is 3–10 engineer-days building batch state, middleware, completion detection, and failure accounting — then maintaining it forever. This is MIT-licensed and small, so the evaluation cost is a spike, not a procurement cycle. The real question is ownership risk, not license cost.
• Use cases to prioritize: multi-step data sync (pull → transform → publish), backfills and migrations, per-tenant report generation, order fulfillment pipelines with a terminal "all steps done" state, and scheduled maintenance jobs that must report success/failure as a unit.
• Scoping/de-scoping lever. With a batch-completion primitive, "show live progress bars per job" can be de-scoped to "notify on completion" — materially cheaper and often sufficient for v1.
• Important framing correction for stakeholders: despite the "Laravel/PHP" label, this is a Symfony Messenger bundle, not a Laravel package. Laravel already ships Bus::batch() natively. So this decision applies to Symfony services only; for Laravel teams, the equivalent decision is "use the framework's batching or not," and this package is not the answer.

When to Consider This Package

Consider it when:

• The service is Symfony-based and uses Symfony Messenger with async transports (AMQP, Redis, Doctrine).
• You need a completion signal for a set of dispatched messages — to trigger a follow-up job, flip a status field, send a notification, or close a workflow.
• The batch is bounded and finite (hundreds to low millions of messages), not an unbounded stream.
• You can accept early-stage maturity: 0 stars, 0 dependents, and a single maintainer. Treat it as "MIT source you may fork," not "vendor-supported infrastructure."
• You want a small surface area — a bundle means less code to audit than a hand-rolled subsystem, and you can vendor/fork it in an afternoon.
• You're running a timeboxed spike (1–2 days) to prove the fan-out/fan-in pattern before committing to build.

Look elsewhere when:

• You're on Laravel — use native Bus::batch() with then/catch/finally callbacks; adopting a Symfony bundle here is a category error.
• You need operational dashboards, retry policies, per-message progress, priority queues, or dead-letter triage — that's a queue-observability product (Horizon-equivalents, Symfony Messenger's failure transport plus tooling), not a completion flag.
• You require vendor support, SLA, security review, or a maintained dependency — zero dependents and zero stars is a genuine bus-factor and abandonment risk.
• Your workload is high-throughput or business-critical, where an unproven package's failure modes (double-completion, lost counters under worker crashes, race conditions on the final message) become incidents.
• You need exactly-once or transactional completion guarantees across database and queue — verify the implementation carefully or build with your own transactional outbox.

Adoption criteria to gate on: code read-through for race conditions around the last-message counter, storage backing (Doctrine vs. Redis) and its failure semantics, behavior on message failure/retry, and a written note that the team owns the fork if upstream stalls.

How to Pitch It (Stakeholders)

To executives: We have recurring product requests of the form "do this heavy thing in the background and tell the user when it's finished" — bulk imports, exports, report generation, mass updates. Today each one needs custom plumbing to know when the work is actually done, which is slow to build and easy to get subtly wrong. This is a small, MIT-licensed component that provides that "batch finished" signal on our Symfony stack. Cost to evaluate is a short engineering spike; the upside is a reusable primitive for a whole class of async features and less bespoke code to maintain. The caveat is maturity — it's an early-stage, single-maintainer project with no adoption yet, so we should pilot it on a non-critical workflow and be prepared to own the code.

To engineering: Symfony Messenger has no native batching; this bundle adds batch tracking so a fan-out of messages can trigger a single completion event. It's small and forkable, but you should review the completion logic for races under worker crashes and retries, confirm the persistence layer and its failure behavior, and decide whether we pin a commit or vendor it. If we adopt, we own it — plan for that. If we're on Laravel, this doesn't apply; use Bus::batch().

Recommendation: Timeboxed spike (1–2 days) on one low-risk workflow, with a written fallback to a small in-house batch tracker if the package's completion semantics don't hold under failure testing.