Swarrot Bundle Laravel Package

Technical Evaluation

Scope correction up front: despite the brief describing a "Laravel/PHP package," swarrot/swarrot-bundle is a Symfony bundle, not a Laravel package. It ships a Symfony Bundle subclass, a DependencyInjection\Extension, compiler passes, and console commands. The underlying library swarrot/swarrot is framework-agnostic PHP, but everything this package adds is Symfony-kernel machinery. That single fact dominates the evaluation.

Architecture fit

• The bundle is a thin configuration/DI layer over swarrot/swarrot: it turns YAML (now PHP) config into per-consumer console commands (swarrot:consume:<consumer> <queue> [connection]), a publisher service (swarrot.publisher), and a chain of decorator "processors" configured by an ordered middleware_stack.
• Fits an existing Symfony 6.4/7.x/8.0 monolith well: consumers become first-class console commands, middleware (ack, retry, signal handling, memory/execution limits, Doctrine reconnect) is opt-in and ordered, and the publisher is configuration-driven via named messages_types.
• Does not fit a Laravel/Lumen application without building an adapter layer: Laravel never registers Symfony bundles, so no config tree, no compiler passes, no auto-generated commands. You would be re-implementing the bundle's value in a hand-written Laravel service provider that wires Swarrot core processors manually — at which point you are maintaining a private fork-in-spirit.
• Deliberate boundary worth noting: the bundle explicitly refuses to manage broker topology ("we don't want to mix infrastructure logic with consuming one"), pointing at odolbeau/rabbit-mq-admin-toolkit. That is defensible design but means exchange/queue/DLQ provisioning is tooling you must own separately (Terraform, IaC, or that toolkit).

Integration feasibility

• Greenfield Symfony service: composer require plus a kernel registration and one config block. Hours, not days.
• Laravel service: two viable paths. (a) Use swarrot/swarrot core only, skip this package, write a ~200–400 LOC Laravel provider + a custom Broker\FactoryInterface equivalent — this is the only credible route and it is custom engineering. (b) Skip Swarrot entirely and use Laravel's native queue/AMQP ecosystem. Path (b) dominates on total cost of ownership.
• Symfony 4.x/5.x estates must stay pinned to older 2.x tags (2.5.0 dropped <5.4; 2.7.0 requires PHP ≥8.2 and Symfony ≥6.4) — no backport path for PHP 8.0/8.1 hosts.

Technical risk

• Ecosystem thinness. 90 stars and 0 Packagist dependents is a high-signal indicator that public production references are scarce. Low dependents also means regressions in edge configurations (custom providers, Doctrine processors, retry extras) are unlikely to be caught by anyone but you.
• Maintainer concentration. Release history is steady but sparse: 1.8.x → 2.7.0 spread over years, with major-version bumps for PHP/Symfony support. Symfony 8.0 support landed in 2.7.0, which suggests one or two people doing routine caretaking, not an active feature roadmap. Bus factor is the material risk, not code quality.
• Data anomaly. "Last release 2026-07-29" is a future-dated timestamp relative to a normal reading of the dataset — verify on Packagist before relying on it for version pinning.
• Removed surface area. NewRelic, Sentry, and RPC configurators were deprecated in 1.8.0 and deleted in 2.0.0. Any org expecting observability integrations out of the box must build them as custom processors.
• Configuration sharp edges. Middleware order is semantic and undocumented beyond the README example; custom processor configurators must be declared as abstract: true services (an unintuitive DI requirement that will bite new contributors).
• Transport coupling. Only pecl (ext-amqp) and amqp_lib (php-amqplib) are supported. Custom providers (e.g., Redis) require implementing FactoryInterface and tagging swarrot.provider_factory.
• No application-level guarantees. No idempotency, no dedupe, no outbox. Delivery semantics are whatever ack/requeue/retry middleware produce.

Key questions

1. Is the target stack exclusively Laravel, exclusively Symfony, or mixed? If Laravel-only, why is this candidate on the shortlist at all?
2. What is the business driver — AMQP specifically, or asynchronous processing generally? If the latter, why not Laravel Queues/Horizon or Symfony Messenger (which has first-party AMQP transport and a comparable middleware model with better support)?
3. Who owns broker topology (exchanges, queues, dead-letter, retry exchanges) if this bundle deliberately does not?
4. Do we need publisher confirms, prefetch/QoS tuning, and heartbeat settings? Confirm which are configurable via this bundle versus the raw connection URL.
5. What is the acceptable incident response time for a message-consumption outage, and can a two-maintainer community project meet it?
6. Are we willing to vendor/fork the bundle if upstream stalls on a future Symfony major?

Integration Approach

Stack fit

• Symfony application: near-native fit. Sequence: install → register bundle → define connection(s) → define one messages_types publisher → implement one ProcessorInterface consumer → configure a minimal middleware stack (exception_catcher, ack, signal_handler, max_messages, max_execution_time) → deploy under supervisor/systemd → add retry + Doctrine processors only after basic flow is proven.
• Laravel application: poor fit for the bundle; acceptable fit for the core library as a deliberate, owned abstraction. Recommend a decision point: either (A) Laravel-native queue with SQS/Redis, or (B) RabbitMQ via php-amqplib or vladimir-yuldashev/laravel-queue-rabbitmq, both of which come with framework integration you won't have to write. Only choose Swarrot core if the ordered-decorator middleware model is specifically what you want and you accept owning the adapter.

Migration path

1. Discovery spike (1–2 days): verify version constraints against the actual PHP/Symfony pins; confirm Packagist metadata; read swarrot/swarrot source for processor semantics rather than relying on the bundle README.
2. Proof-of-concept (3–5 days, Symfony): one publisher, one consumer, one non-critical queue; exercise ack/retry/requeue behavior under induced failure; measure throughput and memory per worker.
3. Adapter build (5–10 days, Laravel route): Laravel service provider, config object, consumer command(s), custom FactoryInterface, and a BlackholePublisher equivalent for the test suite. Budget for this explicitly; it is not "free" integration.
4. Cutover (per queue): dual-publish or shadow-consume, then flip producer, then retire legacy path. Never migrate all consumers at once.
5. Tooling backfill: broker topology provisioning, dashboards, DLQ replay runbook.

Compatibility

• Pin to a specific minor (e.g., ~2.7.0); treat PHP and Symfony major bumps as planned work items, not incidental upgrades.
• pecl vs amqp_lib: choose amqp_lib unless the ext-amqp C extension is already standardized in your base image — it removes a build-toolchain dependency and matches the 2.3.0+ AMQPStreamConnection behavior.
• Test-environment safety is built in via BlackholePublisher (override the swarrot.publisher.class parameter); adopt it in CI to prevent tests from publishing to real brokers.
• Lazy-loadable commands (2.4.1+) mean consumer commands don't inflate every request's container boot cost — confirm this holds on your Symfony version.

Sequencing Config and publisher first (low blast radius), then a single read-only consumer, then middleware hardening (retry, Doctrine reconnect), then scale-out, then topology-as-code and observability. Defer custom providers and custom processors until the baseline is stable; both require interface implementation work and are where the documentation is thinnest.

Operational Impact

Maintenance

• Low code churn but non-zero: expect roughly one release per Symfony major plus PHP deprecation fixes (see 2.6.0's implicit-nullable fix for PHP 8.4). Treat this as a small but permanent upgrade tax rather than a "set and forget" dependency.
• You will own: broker topology, worker supervision, log/metric emission, DLQ tooling, and any observability processor. None ship in the box.
• Mitigation for abandonment: keep the integration surface small (config + one or two processors) so a fork or replacement is a days-not-months exercise. Avoid deeply customizing ProcessorConfiguratorInterface implementations.

Support

• MIT, community-only. No vendor SLA, no commercial backing, small issue tracker. For an internal tool or a non-revenue-critical queue this is acceptable; for a payment or order-fulfilment pipeline it is not, without an internal owner and a documented escalation path.
• Knowledge is concentrated in the README and the core repo. There is no tutorial-level documentation, no migration guide for the 1.x → 2.x config removals, and no documented performance characteristics. Assume you will learn semantics by reading source.

Scaling

• Scale-out model is horizontal: run N supervised workers per queue. Per-worker RSS is the real constraint (PHP process per consumer, no shared runtime), so size nodes by memory × worker count, not CPU.
• Recycling is the primary stability lever: max_messages, max_execution_time, memory_limit, and services_resetter exist precisely to bound memory growth and state leakage (notably Doctrine's EntityManager and stale connections). Configure all of them from day one; doctrine_connection with doctrine_ping guards against broker/DB idle timeouts.
• No built-in autoscaling signal: queue depth metrics must come from the broker (RabbitMQ management API / Prometheus exporter), not from this package. Plan for that integration explicitly.
• poll_interval (default 500000µs) governs empty-queue behavior — too low burns CPU, too high adds latency. Tune per consumer, don't inherit the default blindly.

Failure modes

• Poison-message loop: requeue_on_error: true without a retry processor produces instant redelivery loops that can saturate a worker. Prefer retry + a retry exchange over raw requeue.
• Silent loss: retry_attempts exhausted with no dead-letter path drops the message. Ensure the retry exchange has a terminal destination and an alert.
• Blocked/duplicate processing: no idempotency layer — a crash between processing and ack reprocesses. Consumers must be idempotent by contract, enforced in code review.
• Signal mishandling in containers: signal_handler must be in the stack or Kubernetes SIGTERM will kill mid-message. Verify against your orchestrator's grace period.
• Stale DB connections: long-running consumers accumulate dead Doctrine connections without the Doctrine processors; symptom is intermittent "server has gone away" errors after idle periods.
• Broker disconnect: connection options are largely a URL string; heartbeat/reconnect tuning may require going below the bundle config. Validate behavior under forced broker restart before production.
• Config drift: middleware order is load-bearing and silent when wrong (e.g., ack placed before exception_catcher). Codify the stack in a shared config file and review changes as code, not as YAML edits.

Ramp-up

• A mid-level PHP engineer reaches productive on a Symfony codebase in ~1–2 days: config format, the consumer command, and one processor are easy. Genuine fluency — middleware ordering semantics, extras per configurator, retry/ack interaction — takes ~1–2 weeks and is best acquired by deliberately breaking a non-production queue.
• On a Laravel codebase, add the adapter learning curve plus the "why is there no service provider" conversation: ~1 week of engineering time sunk before the first message flows.
• Documentation debt means onboarding depends on an internal champion. Budget for a short internal runbook (how to add a consumer, how to read a failure, how to replay a DLQ) — without it, this becomes tribal knowledge within two quarters.

Recommendation: Greenfield or existing Symfony 6.4+/PHP 8.2+ estate with genuine AMQP needs — proceed to the 1–2 day spike, then a scoped PoC. Laravel estate — do not adopt this bundle; either use Laravel's native queue stack or adopt the Swarrot core library as an explicitly owned abstraction, and only if its middleware model is a stated requirement rather than an incidental preference.