Laravel Amqp Laravel Package

Technical Evaluation

Verdict (updated for v3.4.2): v3.4.2 is a no-op for the adoption programme — it changes a Docker test-fixture base image (php:8.2.35-fpm) to clear two CVEs in dev containers only. It ships no runtime code, no public surface change, no deprecation, and no behaviour change. The previous verdict on 3.4.1 stands unchanged: the package graduated from an AMQP client wrapper into a microservice toolkit inside a patch bump, and that remains both the adoption opportunity and the governance problem.

The release does, however, change our confidence in the release process, in two ways:

1. Positive: it demonstrates a functioning security-response path for the project's own build/test tooling, and it confirms the 3.4.x line is actively maintained rather than abandoned after the big 3.4.1 drop. That partially answers an open question from the prior assessment (security disclosure process).
2. Negative: the release notes are internally inconsistent with the release itself. The tag is v3.4.2, but the Full Changelog link compares v3.4.5...v3.4.6. Either the notes were copied from a later release, the tag was re-pointed, or releases 3.4.3–3.4.6 exist and we have not reviewed them. This is the second release-hygiene defect in two releases (the first being a toolkit delivered as a patch), and it has direct supply-chain implications: we currently cannot assert which commit v3.4.2 resolves to, nor that we have reviewed every version our constraint allows us to install.

Architecture fit — unchanged from the 3.4.1 assessment.

Integration feasibility — unchanged. No new Composer surface, extensions, or sidecars; everything rides the existing RabbitMQ topology. Backwards-compatibility claims remain concrete and testable. The non-trivial integration item remains the Management API dependency in DeadLetterManager::count()/messages() and MonitoringDashboard: a new network path and credential requirement from web/worker tiers to the broker's management plugin — a security review item, not a code review item. v3.4.2 does not touch this path.

Technical risk (ordered; item 0 is new)

0. Release provenance / unreviewed versions (new, highest immediate risk). The v3.4.2 tag does not match its own changelog range (v3.4.5...v3.4.6). Until resolved we cannot state what code we are installing, nor rule out that 3.4.3–3.4.6 carry changes we have not assessed. Compounded by the fact that a ~3.4.0 or ^3.4 constraint would pull those versions silently.
1. Semver signalling mismatch. Consumers on ^3.4 receive ~13 new capability areas, two auto-registered facades, a new Artisan command, and a new config key without a deliberate upgrade decision. 3.4.2 reinforces the pattern: a patch bump is being used as a general-purpose release channel.
2. Silent no-op on PHP 7.x. #[Retry] is parsed as a comment on PHP 7.x — a retry policy written on 7.4 yields silently zero retries. Still the most dangerous documented behaviour in the package.
3. InMemoryMessageStore as default. Auto-records every publish/consume into process memory: unbounded growth in long-running workers, silent data loss across restart.
4. RPC semantics under-specified. RpcTimeoutException vs RpcException gives useful branching, but no stated idempotency, delivery guarantee, reply-queue lifecycle, or _rpc_error envelope behaviour across trust boundaries.
5. Reflection-based contract resolution (methods(), responseClass(), RetryPolicy::fromAttribute) surfaces drift at runtime, not build time.
6. 3.4.1 release notes remain truncated mid-class-name (ServiceCall...). 3.4.2 does not reissue them.
7. Bus factor / support posture still unknown. The breadth of surface implies a maintenance burden far beyond an AMQP wrapper. Note the only change in 3.4.2 is to the test fixture, which is a weak signal about production-path investment.

Key questions (new items marked ✚)

• ✚ What commit does tag v3.4.2 resolve to, and why does its changelog diff v3.4.5...v3.4.6?
• ✚ Do published releases 3.4.3–3.4.6 exist? If so we need notes for each before any constraint change.
• ✚ Are CVE-2026-109618 / CVE-2026-109619 scoped strictly to the dev container image, with no published image or runtime artefact from this project affected?
• Is the 3.4.1/3.4.2 version numbering deliberate? Will the maintainer re-version the toolkit drop as 3.5.0/4.0.0, or publish a feature-gate note?
• Can we get the complete 3.4.1 release notes and an explicit list of anything deprecated or changed in behaviour?
• What are the delivery guarantees of Rpc::call()? What happens to a reply arriving after RpcTimeoutException?
• Does _rpc_error propagate raw exception messages/stack context across service or trust boundaries?
• What is the memory ceiling / eviction policy for InMemoryMessageStore, and is setMessageStore() attach-time or per-call?
• Does AmqpEventListener capture all Laravel events when enabled, or only marked ones? Payload serialisation and size cap?
• Is the Management API call path authenticated, TLS-capable, and per-connection configurable?
• Who maintains this, what is the security disclosure process (partially evidenced by 3.4.2), and is there an LTS/backport policy for the 8.x–13.x matrix?
• Is there supported feature-flag granularity to run RPC and platform features independently?

Integration Approach

Stack fit — unchanged and still strong: Laravel 8–13, PHP 7.3–8.5, PHPUnit matrix aligned. One dependency can serve older and newer services during transition, and it is a genuine fit for teams on RabbitMQ wanting RPC, retries, and DLQ tooling without gRPC infrastructure or a separate orchestrator.

Caveats unchanged:

• PHP 7.3 support caps the design (class constants over enums, attributes ignored at runtime) and produces the silent-#[Retry] trap. Recommend we set our own floor at PHP 8.1+.
• Opinionated toward RabbitMQ. SQS/Redis teams cannot adopt the platform layer. Fine if RabbitMQ is strategic; a fragmentation risk if not.

v3.4.2 adds no fit considerations — it is a dev-fixture bump. Take it or skip it; do not treat it as a milestone.

Migration path — still none. Existing publish/consume code, handler signatures, config layout, and the 3.4.0 public surface are unchanged; new features are opt-in and the event bridge is off by default. 3.4.2 does not alter this. The only "migration" teams face is learning and choosing, not changing code — still the strongest property of the 3.4.x line and the headline for internal comms.

Compatibility

Sequencing — four gated phases retained; the 3.4.2 delta is folded into Phase 0. Do not let the "patch release" framing collapse this into a single upgrade ticket.

MessageStore and the async Laravel event bridge remain Phase 5+, demand-driven. Ship InMemoryMessageStore only in tests; production use requires a durable backend implemented against MessageStoreInterface first. The event bridge needs data-classification sign-off before opt-in — a wildcard listener serialising Laravel events to a broker is a data-egress surface.

Operational Impact

Maintenance

• Tighten the pin (changed by 3.4.2). The prior recommendation of ~3.4.0 is withdrawn pending provenance resolution: with a tag/changelog mismatch on record, a range constraint can silently install unreviewed versions. Pin exact (3.4.1 or a verified 3.4.2) for all services not actively piloting new features; move to a range only after Phase 0 clears.
• Add a release-watch step to the dependency policy: every laravel-amqp release gets a tag↔changelog sanity check before it can enter the fleet. This is cheap and catches exactly the class of defect 3.4.2 exhibits.
• Support for PHP 7.3 while shipping PHP 8 attributes means two code paths. Internal standard: PHP 8.1+ for any use of retries, sagas, or RPC, documented as a platform rule.
• Standardise on one access path where the facades and the underlying accessors (Amqp::rpcDispatcher(), Amqp::dashboard()) overlap, to avoid a fragmented codebase.
• The package's surface roughly doubled in a patch; the 3.4.2 release adds no surface but also adds no documentation, runbooks, or examples — the enablement debt from 3.4.1 is entirely still outstanding.

Support

• New on-call artefacts still required: DLQ replay/purge runbook, RPC timeout triage, causation-id trace lookup, amqp:monitor --json scrape target added to the monitoring estate.
• amqp:monitor --json remains the primary integration point for the existing observability stack — prefer it over bespoke dashboards.
• Security review still needed for (a) Management API credentials/network path, (b) _rpc_error remote-exception exposure, (c) event-bridge payload classification. (d) new: confirm the two CVEs are confined to dev tooling and that no published artefact of this package or its images is affected.
• Escalation path to the maintainer remains unclear. The 3.4.2 CVE fix is evidence that someone responds to security items, but not evidence of an SLA, a disclosure policy, or a backport commitment. Establish contact before Phase 3, when this becomes load-bearing infrastructure.

Scaling — unchanged by 3.4.2.

• RPC over RabbitMQ scales with the broker, not a separate fleet — operationally cheaper than gRPC. But every synchronous Rpc::call() blocks a worker for up to defaultTimeout. Bound the timeout explicitly and globally (Rpc::defaultTimeout()) and size worker pools on worst-case blocking, not average.
• MonitoringDashboard fans out to the Management API; with many queues polled from many replicas this can load the management plugin. Scrape from one place (a single scheduled amqp:monitor) rather than per-replica.
• If MessageStore is ever attached fleet-wide, throughput and storage become first-class capacity concerns — every publish and consume becomes an extra write. Largest hidden cost in the release; must not be on by default.
• ServiceRegistry::autodiscover() implies a startup scan of RpcService subclasses; verify boot-time cost at scale before relying on alias-based discovery.

Failure modes

We still cannot assert "no deprecations" for 3.4.1, and we now additionally cannot assert "all versions in range reviewed." Both remain open failure modes.

Ramp-up — cost estimate unchanged; one small reallocation.

• Still ~2–3 days per service team for Phase 1 (validation only), a half-day enablement session for teams entering Phases 3–4, and ~1 week of platform-eng time for the DLQ runbook, lint rule, and dashboard wiring. Add ~2 hours for the provenance/tag verification in Phase 0 — trivial against the risk it retires.
• Publish one golden path, not thirteen features. Two recipes only: (1) typed RPC with a bounded timeout and idempotent handler; (2) DLQ inspection/replay via amqp:monitor and DeadLetterManager. Everything else documented but not promoted. v3.4.2 earns no recipe.
• Named owners. One TPM owner for the adoption programme, one platform engineer as package SME. Route all 3.4.x questions through them to build a single internal knowledge base.
• Re-evaluate at Phase 2 exit. Standardisation on RPC/sagas is decided on pilot evidence, not feature list. If RPC round-trip latency or timeout blocking proves unacceptable for our traffic profile, we keep the observability and reliability wins and stop — a good outcome for capability we received "for free" in a patch bump.
• Framing for stakeholders: v3.4.2 is housekeeping and requires no action beyond the pin tightening. It is not a signal to accelerate. The Phase 0 gate remains open on the 3.4.1 notes and now also on version provenance.