Messenger Monitor Bundle Laravel Package

Getting Started

This is a Symfony bundle, not a Laravel package — that is the single most important thing to internalize before you spend time on it. It hooks into Symfony's DI container, Kernel, web profiler, and the Symfony Messenger component. There is no service provider, no facade, no publishable config. composer require karo-io/messenger-monitor-bundle in a Laravel app will install files you cannot meaningfully wire up without porting them.

If you still want to evaluate it:

1. Read the README's configuration section first — that is where the transport list and failed-message transport are defined. That config tree is the whole feature surface.
2. Spin up a throwaway Symfony skeleton (composer create-project symfony/skeleton), add symfony/messenger and the web profiler, then enable the bundle in config/bundles.php.
3. Configure at least one real transport (Doctrine or AMQP) and push a few messages through it.
4. Open any page in dev and look at the profiler toolbar — that is the intended first use case: glance at queue depth and failed messages without leaving the app.

For a Laravel developer, the practical "first use case" is usually stealing ideas, not adopting the code: understand what a Messenger monitoring panel surfaces (per-transport pending count, failed transport contents) and map that to Horizon, Pulse, or a small Artisan command of your own.

Implementation Patterns

The bundle is designed around the Symfony profiler lifecycle: a DataCollector snapshots transport state on each request in dev, and the profiler UI renders it. Everything else is configuration.

Patterns that make sense if you are actually on Symfony:

• Local dev feedback loop. Keep it enabled only in dev/test. Confirm consumers are running and the queue is draining while you iterate on a handler.
• Transport comparison. With multiple transports configured (sync, doctrine, amqp), the panel is a quick way to see which one is backing up — useful when a handler starts throwing and messages retry into the failure transport.
• Failed-message triage. Point the bundle at your failure transport and pair it with messenger:failed:show / :retry in the console. The panel tells you that there are failures; the console is where you act.

For a Laravel codebase, the honest mapping is:

• Queue depth / throughput → Laravel Horizon (Redis) or php artisan queue:monitor.
• Failed jobs → failed_jobs table, queue:failed, queue:retry, and the Horizon failed-jobs UI.
• At-a-glance dashboard → Laravel Pulse cards.
• Per-request snapshot in the debug toolbar → Laravel Debugbar plus a custom collector if you really want it.

If your team runs Symfony Messenger inside Laravel (rare, via a bridge or a legacy service), the sane integration is to wrap the bundle's conceptual checks in a small Artisan command that shells out to the transport's native introspection, rather than attempting to boot a Symfony bundle inside a Laravel container.

Gotchas and Tips

• Archived. Treat this as read-only reference code. No security patches, no support for newer Symfony versions, no PHP 8.x guarantees beyond what was current at archive time. Do not put it on a production dependency path without forking and pinning.
• Symfony-only by construction. It expects Bundle, Extension, Configuration, and profiler tags. Porting to Laravel means rewriting the collector and config layer — at which point you have written your own package.
• Snapshot cost is not free. Counting messages means hitting the transport: COUNT(*) against a Doctrine table, queue_declare (passive) against AMQP, LLEN against Redis. Doing this on every request in dev is fine; doing it per-request in production is not.
• Zero counts can lie. Some transports only report on queues that have been declared, and passive AMQP declares fail silently if the queue does not exist yet. A "0 pending" reading often means "queue not declared," not "queue empty."
• Failed-message panel is config-dependent. If you have not explicitly named the failure transport in the bundle config, the panel renders empty and looks broken. Check the config tree before filing a bug.
• Debugging path: bin/console debug:container --tag=data_collector to confirm the collector is registered, then check profiler storage — if the toolbar shows nothing, the collector usually was not tagged or the bundle was not enabled.
• Extension point that actually exists: implement your own DataCollector following the bundle's shape, or skip the bundle entirely and write a bin/console command that loops over messenger.transport.* services and prints counts. The command is ~30 lines and has no archive risk.
• Recommendation for Laravel teams: use Horizon or Pulse. This bundle's value here is as a design reference for what a Messenger/queue health panel should show — pending depth, failed transport contents, per-transport breakdown — not as a dependency.