Mq Notification Bundle Laravel Package

Getting Started

• Install with Composer (composer require fintem/mq-notification-bundle). The current release is 1.3.0, whose headline change is Support Symfony 4 — so on Symfony 4 you can install it without immediately forking. Check the package's composer.json first: it still pins Symfony 3.4/4.x and PHP 7.x, and there is no Symfony 5+/PHP 8 support. On newer stacks you will still need to fork and bump constraints before you can install it.
• Register the bundle in your kernel (AppKernel::registerBundles() on Symfony 3.4, config/bundles.php on Symfony 4).
• Look at these files before writing any code, in this order:
  1. README.md — the only place the intended send/receive workflow is described.
  2. DependencyInjection/*Extension.php and Configuration.php — this is the actual config tree (AMQP host/port/vhost/credentials, exchange, queue, routing key). Treat this as the source of truth; the README often lags behind.
  3. Resources/config/services*.yml — the service IDs and tags you'll inject or subscribe to. Note that 1.3.0's Symfony 4 support means these are still likely explicit YAML definitions, not autowired services — don't assume autoconfiguration.
  4. Any Command/ or Consumer/ classes — that's your worker entry point.
• Configure the AMQP connection and the exchange/queue names in config/packages/mq_notification.yaml (Symfony 4) or app/config/config.yml (Symfony 3.4). Keep credentials in env vars, not in the committed config — but verify env resolution works (see Gotchas).
• First use case: a fire‑and‑forget notification. Publish a notification from a controller/service, run the bundle's consumer as a worker in a second terminal, and confirm in the RabbitMQ management UI that the message is published, routed, and consumed. Once that round trip works, wire the consumer's dispatched Symfony event into your own subscriber — that's the actual integration point.

Implementation Patterns

• Publish side — event in, AMQP out. The bundle sits between the Symfony event dispatcher and AMQP. The idiomatic pattern is: your domain code dispatches an event (or calls the bundle's publisher service), the bundle serializes the notification and publishes it to a configured exchange with a routing key. Keep the call site behind your own thin service (NotificationPublisher) so your domain code depends on an interface, not on the bundle.
• Consume side — AMQP in, event out. Run the consumer as a long‑running worker. It pulls from the queue, deserializes, and re‑dispatches onto Symfony's dispatcher. Your application code is just an event subscriber; you never touch AMQP directly. This is the main reason to use the package over raw php-amqplib: it gives you the messaging transport and leaves the handling logic to normal Symfony listeners.
• Symfony 4 wiring. With 1.3.0 you can now use the standard Symfony 4 bundle registration and config/packages/ layout. Service definitions still come from the bundle's YAML, so inject the publisher by ID (or alias it to your own interface) rather than relying on autowiring to discover it.
• Routing topology. Decide up front whether you need fanout (every consumer gets a copy — e.g. audit logging plus email) or direct/topic routing per notification type. Bind queues to the exchange in the bundle config or in RabbitMQ itself; mismatched routing keys are the #1 cause of "published but never consumed."
• Decouple producer and consumer deploys. Producer and consumer are separate processes and often separate deployments. Keep the message payload versioned (a version or type field) so a new producer can't crash an old consumer mid‑deploy.
• Worker supervision. Run consumers under systemd or Supervisor with auto‑restart, one process per queue, and a --time-limit/--memory-limit style restart if the bundle's command supports it. Never consume in a web request.
• Testing. In tests, replace the publisher with an in‑memory stub that records dispatched notifications, and invoke your event subscribers directly rather than going through RabbitMQ. Keep a small number of true integration tests that run against a real or Dockerized broker.
• Idempotency. At‑least‑once delivery is the norm. Give each notification a stable ID and make handlers safe to run twice (dedupe table, upsert, "already sent" check).

Gotchas and Tips

• Vendor risk is still the headline. Two stars, zero dependents, long gaps between releases (the 1.3.0 "Support Symfony 4" bump only narrows the gap slightly — it does not signal active maintenance). Pin the exact version, read all of its source (it's small), and budget for a fork. Assume you own this code.
• The 1.3.0 change is narrow. "Support Symfony 4" means the Symfony 4 constraint/registration works — it does not mean Symfony 5+/PHP 8 support, modern autowiring, or a rewrite of the deprecated glue. Old bundles typically still use deprecated APIs (ContainerAware, YAML service definitions without autowiring, string event names). Expect friction upgrading. The AMQP layer itself is the valuable part; the Symfony glue is easy to rewrite if needed.
• Version pinning after the release. If you were previously stuck on the pre‑1.3.0 tag, re-read composer.json after upgrading — the Symfony constraints moved, and a transitive bump can change which minor you resolve to. Lock it deliberately.
• Extension vs library. Confirm whether it needs the amqp PHP extension or uses php-amqplib. They have different failure modes and packaging implications for your base image.
• Ack/nack and poison messages. A handler that throws on a malformed message can loop forever if the bundle nacks‑and‑requeues. Configure a dead‑letter queue and a retry limit; otherwise one bad payload wedges the worker.
• Prefetch/QoS. Default prefetch can be unset, letting one consumer hoard the queue. Set a small prefetch for slow handlers so work spreads across workers.
• Long‑running worker rot. Stale Doctrine connections, growing memory, and stale container state accumulate. Reconnect on failure and recycle the worker periodically.
• Serialization compatibility. Whatever format it uses (PHP serialize, JSON, etc.), producer and consumer must agree. PHP serialize is brittle across class changes — prefer JSON with explicit DTOs if you can override the serializer. The serializer is usually the cleanest extension point: swap it for your own service to control the payload shape.
• Event naming. Consumers re‑dispatch events with string names; there's no compile‑time check. Document the event names and payload contracts in your own code, and add a subscriber that logs unknown event types loudly.
• Debugging checklist: RabbitMQ management UI for queue depth and bindings → worker logs at debug level → confirm the exchange actually has a binding to your queue → confirm the routing key matches exactly → publish a test message by hand.
• Config quirks. Old bundles often read discrete config keys rather than a DSN. Check whether values are resolved at container compile time (so %env()% may not work as expected) and clear the cache after every config change — especially important on Symfony 4, where the compiled container is aggressive about caching.
• Extension points worth knowing: the serializer, the event classes the consumer dispatches, subscriber priority (to order handlers), and the exchange/queue declarer. Everything else is thin glue you can replace.