- Is fintem/mq-notification-bundle a Laravel package?
- No. Despite the message-queue notification framing, it is a Symfony bundle that registers through Symfony's bundle kernel and a DependencyInjection extension, and it depends on symfony/framework-bundle and symfony/event-dispatcher. Laravel has no bundle registration mechanism, and its event dispatcher uses a different listener contract, so there is no supported integration path.
- Can I install fintem/mq-notification-bundle in a Laravel app with Composer?
- It is technically possible to require it, but you should not. Pulling it in drags symfony/framework-bundle into your dependency graph and will collide with the Symfony component versions Laravel already pins. The practical result is a dependency conflict, or a package that installs but cannot be bootstrapped by Laravel's container.
- What does fintem/mq-notification-bundle actually do?
- It publishes a notification message envelope to an AMQP broker and runs a consumer that pops messages off the queue and re-dispatches them as Symfony events for listeners to handle. That produce, publish, consume, dispatch loop is the core of the package. Functionally it mirrors Laravel's queued notifications, just wired for Symfony.
- Is fintem/mq-notification-bundle still maintained?
- No. The repository has had no releases since July 2018, has roughly 2 stars and 0 dependents, and shows no evidence of CI or test coverage. There is no community to absorb a CVE or a RabbitMQ protocol change. Treat any dependency on it as unmaintained code your team now owns.
- Does it support Laravel 10/11 and PHP 8.2+?
- Almost certainly not. The package was written for the PHP 7.0 to 7.2 and Symfony 2.x to 4.x era, so its composer.json constraints are unlikely to resolve against a modern PHP 8.2+ and Laravel 10/11 dependency graph. Check the declared constraints before assuming anything, and expect a conflict rather than a clean install.
- What is the wire format of the notification message and its AMQP topology?
- That is not documented in the overview and must be verified by reading the source. The key questions are whether the envelope is JSON, PHP serialize, or a custom format, and whether exchanges, queues, and bindings are declared in code, declared from config, or assumed to pre-exist on the broker. Extracting that contract into a written spec is the first step of any migration.
- How does it handle failed notifications, retries, and dead letters?
- The overview claims retry handling for failed notification jobs, but the actual semantics are unverified. It is unclear whether a listener exception triggers nack-and-requeue, ack-and-drop, or dead-letter routing, and unbounded requeue loops are a real risk. Confirm ack/nack behaviour, retry limits, DLQ handling, and whether the consumer is idempotent on an envelope id before relying on it.
- Is it safe to consume broker payloads produced by this package?
- Treat it as an untrusted-input boundary. A consumer that deserializes broker data and dispatches events from it is an injection surface, so verify the serialization format and never call unserialize on broker-supplied payloads. A versioned JSON envelope with an explicit type field is the safer contract to port forward.
- What should I use instead for asynchronous notifications in Laravel?
- Laravel already ships the pattern: implement ShouldQueue on your notifications, run supervised queue workers, and add Horizon for retries, backoff, and failed-job handling. If you specifically need RabbitMQ, use a maintained AMQP bridge or php-amqplib with publisher confirms, manual acks, bounded retries, and a dead-letter queue. If you want this package's design, port the envelope and topology rather than the code.
- Can I fork fintem/mq-notification-bundle or extract its logic?
- The package is MIT licensed, so forking is generally acceptable, but confirm ownership and licensing with the original maintainers before redistributing. The transferable logic is small, roughly a message envelope, an AMQP producer, and a consumer that dispatches events, so a clean reimplementation on Laravel primitives is usually cheaper than maintaining a fork. Keep contract tests built from recorded fixtures so producers and consumers stay wire-compatible.