Php Amqp Client Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for AMQP 1.0 messaging. This release is the first concrete evidence of what the bundle actually gives you out of the box: a Symfony-managed client with a factory abstraction (TerminusFactoryInterface) and a receiver endpoint abstraction (OpenReceiverEndpoint). That is enough to decide whether to adopt a thin integration layer or keep hand-rolling sigbits/php-amqp-client wiring in your own container configuration.
• Consumer/worker architecture roadmap. OpenReceiverEndpoint::deliveries() makes first-class delivery iteration available, which is the primitive behind ordered consume → process → ack/nack loops, prefetch/backpressure tuning, and graceful shutdown. If your roadmap includes moving from cron-driven batch jobs to long-lived streaming consumers, this is the enabling API — treat it as a gate on that roadmap item rather than a nice-to-have.
• Retry and dead-letter semantics. TerminusFactoryInterface::modified() lets application code produce AMQP Modified delivery-state outcomes (with failed/undeliverable-here semantics) instead of a blunt reject. That converts "how do we handle poison messages?" from a bespoke design question into a supported configuration decision — relevant to on-call load, SLOs on queue depth, and whether you need a separate DLQ service.
• Platform baseline commitment. PHP ^8.3 and Symfony ^6.4 || ^7.4 || ^8.1 are hard floors. Adopting or upgrading this release is implicitly a decision about your runtime upgrade calendar; it should be sequenced with, not after, the PHP/Symfony upgrade.
• Dependency consolidation. Raising the baseline to sigbits/php-amqp-client ^1.4 means one coordinated bump instead of two independent library tracks. Worth folding into the next dependency-hygiene window rather than scheduling separately.

When to Consider This Package

Consider it when all of the following hold:

• Your service is Symfony-based (this is a bundle: it registers services and configuration through Symfony's DI/HttpKernel, not Laravel's service provider and queue system). If the codebase in question is Laravel, this is the wrong tool — look at vladimir-yuldashev/laravel-queue-rabbitmq or a direct php-amqplib integration instead.
• You are already committed to, or actively evaluating, AMQP 1.0 rather than 0-9-1. The Modified outcome and terminus/receiver endpoint abstractions are AMQP 1.0 concepts; you get little value otherwise.
• You need streaming consumers with explicit outcome control (modified/failed/undeliverable-here), not just fire-and-forget publishing.
• You can satisfy PHP 8.3+ and are on Symfony 6.4, 7.4, or 8.x. Teams still on PHP 8.1/8.2 should defer.
• You are comfortable with pre-1.0 semantics. A 0.x version is an explicit signal that the public surface — including the interfaces this release adds — can change without a deprecation cycle.

Look elsewhere when:

• The stack is Laravel, or the messaging requirement is simple pub/sub over RabbitMQ with no need for AMQP 1.0 features.
• You need a stable, semver-guaranteed API for a long-lived platform component. Wait for 1.0 or wrap the bundle behind your own internal interface so a 0.8/0.9 churn doesn't ripple through your domain code.
• You need vendor-backed support, SLA, or a broad maintainer base. This is a small-ecosystem package; the verification evidence is make ci plus a clean-install check, not a documented compatibility matrix across versions.
• Your platform team requires published benchmarks, upgrade guides, or a deprecation policy — none of those exist at 0.7.

Also flag two specific traps: the Symfony ^8.1 allowance is ahead of most production estates, so the "supported" range is wider than what your team has realistically validated; and the dev branch alias moving to 0.7-dev means anything pinned to 0.7.x-dev will shift under you.

How to Pitch It (Stakeholders)

For executives: A small open-source integration library for our Symfony services has released v0.7.0. It adds two capabilities we would otherwise build ourselves — reliable iteration over incoming messages, and standardised signalling for "this message failed, retry or dead-letter it." It requires PHP 8.3 and current Symfony, so it aligns with our existing upgrade path rather than forcing a new one. Cost is zero in licence terms; the real cost is engineering time to adopt and the risk that a pre-1.0 library changes its API. Recommendation: pilot on one non-critical consumer, do not standardise platform-wide until 1.0.

For engineering: v0.7.0 raises the sigbits/php-amqp-client baseline to ^1.4 and exposes two convenience APIs — OpenReceiverEndpoint::deliveries() for delivery iteration and TerminusFactoryInterface::modified() for constructing AMQP Modified delivery states. No deprecations or removed methods are announced, but this is a 0.x package, so treat the new interfaces as unstable. Constraints: PHP ^8.3, Symfony ^6.4/^7.4/^8.1, client ^1.4. Verification is make ci plus a clean composer require ... :^0.7. Action: bump in a branch, confirm our consumer loop and retry paths behave, and keep the bundle behind an internal adapter so a future breaking minor doesn't reach our domain layer. This is a Symfony bundle — do not propose it for the Laravel services.