Enqueue Bridge Laravel Package

Getting Started

• Prerequisites. PHP 7.1–7.3 era, Symfony 4.1/4.2 with the experimental Messenger component, plus the Enqueue stack you actually intend to use (enqueue/enqueue and one of enqueue/amqp-ext, enqueue/amqp-lib, enqueue/redis, enqueue/pheanstalk, etc.). Confirm your Messenger version first — the bridge targets the pre-4.3 transport API and will not compile against modern Messenger.
• Install and pin. composer require sroze/enqueue-bridge:0.2.0 — use the exact tag, not ^0.2. There is no Flex recipe and no 1.x, so treat it as a vendored adapter.
• First place to look. src/ for the Messenger TransportInterface implementation and its factory, and DependencyInjection/ (or Resources/config/services.yaml) for how it auto-registers with the transport factory tag. Skim the factory's createTransport() method: the DSN parsing there tells you exactly which brokers are supported and in what string format.
• First use case. The bridge exists so you can keep a single Enqueue connection/DSN and reuse Enqueue producers and consumers while still publishing through Symfony's MessageBusInterface. If you are already running Enqueue in one part of the app and adopting Messenger in another, this is the seam that avoids running two competing brokers.
• Minimal wiring. Register the bridge's transport factory as a service (tagged messenger.transport_factory if it isn't auto-configured), then reference a transport in config/packages/messenger.yaml using an Enqueue-backed DSN, e.g. amqp://guest:guest@localhost:5672/%2f/messages or redis://localhost:6379/messages. Dispatch a message through the bus and confirm the payload lands on the broker with the broker's own tooling (rabbitmqctl, redis-cli, etc.) before touching the consumer.

Implementation Patterns

• Producer side. Dispatch as normal through MessageBusInterface; the bridge serialises the Envelope and hands it to an Enqueue Producer from the Context. No changes are needed to your command/handler code — this is the point of the bridge. Keep the handler and the dispatch site ignorant of Enqueue.
• Consumer side. Run bin/console messenger:consume <transport> in a worker (Supervisor/systemd). The bridge wraps the Enqueue Consumer and polls the queue on each get(). Because polling is delegated to Enqueue, prefetch/qos settings come from the Enqueue Context, not from Messenger.
• Share the connection config. The critical operational pattern is that the web process (producer) and the worker (consumer) must resolve to the same Enqueue ConnectionFactory/Context. Extract the DSN into an env var (ENQUEUE_DSN) and let Messenger transport config reference it. Mismatched DSNs are the single most common "messages disappear" cause with this package.
• Keep serialisation consistent. The bridge does not normalise payloads across the Enqueue↔Messenger boundary. Pick one serialiser — typically Enqueue's SymfonySerializer with the same serializer setup you use in Messenger — and use it for both producing and consuming. If you have any legacy Enqueue producers already writing to the same queue, they must use the same serialiser and message format, or the consumer will silently fail to decode.
• Reuse an existing Enqueue context. If you already build an Enqueue Context in a service provider (for a legacy publisher), inject that same instance into the bridge factory rather than constructing a second one. That is the whole reason to choose a bridge over writing a Messenger transport from scratch.
• Handlers stay Messenger-native. Tag handlers with messenger.message_handler (or rely on _instanceof autoconfiguration) exactly as you would with the built-in transports. Do not add Enqueue-specific glue to handlers — that is the coupling the bridge is meant to hide.
• Extension point. If you need a broker the factory doesn't recognise, subclass or wrap the factory and return your own TransportInterface implementation; the bridge's transport class is thin enough to copy if the factory is the only obstacle.
• Isolate the seam. Even for a short-lived bridge, bind the bridge behind a first-party interface (a small MessagePublisher service) and inject that into controllers. When it comes time to drop the bridge, only the one binding changes.

Gotchas and Tips

• It is abandoned and pre-1.0. The 0.2.0 release note — "last known working bridge before moving it" — is a warning. Pin exactly, commit the lockfile, and consider repositories vendoring or a fork in your own namespace rather than depending on the upstream repo long-term. Budget a removal ticket at adoption time.
• Messenger API drift is the real breakage risk. The 2018-era Messenger interfaces (TransportInterface, ReceiverInterface, Envelope handling) were reshaped significantly in Symfony 4.3 and again after. Before you rely on this, write one failing test that dispatches and consumes a round-trip message, and run it against your Symfony version. If it does not compile, do not patch the bridge — write a ~100-line transport of your own against the current interface.
• No Flex recipe, no autoconfiguration guarantees. You will likely wire services.yaml by hand and may need to add the messenger.transport_factory tag yourself. Check bin/console debug:container --tag=messenger.transport_factory to confirm registration.
• Queue naming is Enqueue's, not Messenger's. Messenger's routing maps to a transport; the queue/topic name is baked into the Enqueue DSN. Renaming a Messenger transport does not rename the queue. Change one, and you get a worker consuming an empty queue with no error.
• Serialisation failures are silent. A message produced with PhpSerializer and consumed by SymfonySerializer (or vice versa) typically surfaces as a decode exception on the consumer process, not on dispatch. Log at the worker level and inspect the raw payload with the broker CLI when in doubt.
• Delayed delivery, priorities, and dead-lettering are not uniform. The bridge exposes whatever Enqueue supports per broker; do not assume a feature works across AMQP, Redis, and Beanstalk equally. Test the specific broker you deploy. Retry/DLQ behaviour is Enqueue's (or Messenger's), not the bridge's — do not look for retry configuration in the bridge.
• Worker liveness. Because consumption is a poll loop through Enqueue, --time-limit/--memory-limit on messenger:consume matter more than usual; long-running workers leak connections on some brokers. Run workers under Supervisor with --time-limit=3600 and let Supervisor restart them.
• Debugging tips. Wire a PSR-3 logger into the Enqueue Context (Enqueue ships an Interop\Queue logger) and set it to debug; the bridge itself logs little. Use the broker's own inspection tooling for anything that "looks delivered but isn't consumed", and confirm the consumer's Context is pointed at the same vhost/namespace as the producer's.
• Do not build public extension points on it. Any custom factory or transport subclass you write is coupled to a package that will not be maintained. Keep customisations inside your own adapter layer, not in a fork you publish, and expect to reimplement rather than upgrade.