Messenger Central Laravel Package

Product Decisions This Supports

• Developer-experience investment in async messaging. The tool collapses the feedback loop for anyone working with Symfony Messenger: transports, routing, worker lifecycle, retries and the failed-message queue are all visible in one terminal instead of spread across messenger:consume panes, log tails and messenger:failed:show commands. That makes "how much do we invest in making our queue layer approachable?" a measurable onboarding/support-cost question rather than a vibe.
• Failure-handling policy (retries, DLQ, replay). The failed-messages view — paged list, full stack traces, delete, and requeue as-is or after editing the payload JSON — is a concrete UX for a decision most teams defer: do we treat failed messages as an engineering ticket, or as an operator-level replay action? Standing this up in dev is the cheapest way to find out which policy you actually want in production.
• Concurrency roadmap. The package exposes Symfony 8.2's per-worker concurrency (amphp/parallel) with a live view of in-flight messages and per-worker throughput. That gives you real, local evidence for or against "scale by adding workers" vs "scale by adding concurrency per worker" before you commit to infrastructure or refactor handlers to be concurrency-safe (stateless, idempotent, no shared mutable state).
• Build vs buy for internal ops tooling. Teams routinely hand-roll a worker dashboard or a failed-message admin page. This is a credible "buy" (adopt, ~zero integration cost) against weeks of internal tooling — with the caveat that its scope is the developer's terminal, not a production operations console.
• Transport and broker evaluation. Sidebar-level visibility of waiting messages, per-transport options and routing is a fast way to sanity-check a Doctrine/Redis/AMQP topology and its routing configuration during a migration or a broker swap.
• Roadmap input on worker stability. The restart policy (immediate restart for self-terminating workers, backoff for crashes) and per-worker MESSENGER_CONSUMER_NAME are opinionated defaults. Adopting them tells you quickly whether your handlers leak connections, exit unexpectedly, or misbehave under restart — feedback worth having before those behaviours reach staging.

When to Consider This Package

Adopt when:

• You run Symfony 8.1+ with Messenger as a material part of your architecture, and developers currently juggle multiple messenger:consume terminals during development.
• Your team is on PHP 8.4.1+ on Linux, macOS or WSL — note this is Unix-only; native Windows developers are excluded (WSL counts, but verify it's actually their setup).
• You are evaluating or already using Symfony 8.2 concurrency, or operate Redis transports where unique consumer names matter.
• You want failed-message triage and replay to be a routine, self-service developer action rather than an interruption.
• You accept v0.1.0 risk: pre-1.0, no compatibility promise, expect churn. Pin the version, keep it in require-dev, and never on a production path — the command deliberately refuses to run outside debug mode without --force, which is the right guardrail but also confirms the intended scope.

Look elsewhere when:

• The stack is Laravel. This is the important caveat: despite the framing, this is a Symfony Messenger tool, not a Laravel queue tool. Laravel's queue workers (queue:work, Horizon, failed-jobs table) are a different subsystem; nothing here applies unless you have deliberately introduced Symfony Messenger into a Laravel or standalone-PHP codebase. For standard Laravel, Laravel Horizon is the direct analogue (and is production-grade); for failed-job UX, Laravel's queue:failed tooling or a package like Horizon's UI covers similar ground.
• You need production observability. This is a local development cockpit. Metrics, alerting, historical trends and multi-host visibility belong to your APM/observability vendor.
• You can't take a pre-1.0 dev dependency, or you need Windows-native support, PHP < 8.4.1, or Symfony < 8.1.
• Your pain is handler design, not worker visibility — no dashboard fixes non-idempotent or non-concurrency-safe handlers.

How to Pitch It (Stakeholders)

For executives (one paragraph): A small, free, open-source developer tool that gives engineers a single terminal screen to see and control message-queue workers while building. It reduces the day-to-day friction and onboarding cost of our async messaging layer — the part of the system where silent failures and stuck messages usually hide — without touching production, adding infrastructure, or requiring procurement. Cost is a dev-only dependency and an afternoon of evaluation; the upside is faster diagnosis of failed and retried messages and early evidence on whether we should scale workers or scale concurrency. Main caveats: it is a v0.1.0 tool for Symfony applications (not our Laravel queue stack, if that's what we run), it is Unix-only, and it is explicitly a development aid rather than a monitoring product.

For engineering: Read this as a zero-integration, dev-only cockpit for Symfony Messenger: transports with routing and masked credentials, keyboard-driven start/stop/scale of real messenger:consume processes, live rates and per-worker handling times, a full failed-message workflow (inspect stack traces, delete, requeue as-is or after editing the payload JSON), worker output including dump(), and ? for every binding. Two things to weigh before adopting: it requires PHP 8.4.1+ / Symfony 8.1+ on Linux, macOS or WSL, and it's a first release with no stability promise — pin it in require-dev, and treat its restart/backoff defaults and MESSENGER_CONSUMER_NAME behaviour as opinions to validate against our handlers rather than gospel. If we're on Laravel's queue, this doesn't apply to us; Horizon is the equivalent conversation.