Rabbitmq Supervisor Bundle Laravel Package

Technical Evaluation

Architecture fit. phobetor/rabbitmq-supervisor-bundle is a Symfony bundle, not a Laravel package — the first and most important finding. It provides console commands and a Supervisor program-generation layer for running RabbitMQ consumers as long-lived workers under supervisord. Fit is therefore strong for Symfony applications with PHP consumer daemons and weak-to-absent for a Laravel codebase, which would use Horizon/queue workers or a hand-rolled Supervisor config instead. If the reviewing team's stack is Laravel, this is a non-starter unless adopted as a standalone CLI tool with config bootstrapped outside Symfony's kernel.

Integration feasibility. The bundle is small, config-driven, and generates Supervisor program blocks; it does not itself broker RabbitMQ connections (that is php-amqplib or a Symfony messenger transport). Adoption is therefore mostly a configuration and process-supervision exercise rather than a code-integration exercise. The 3.3.0 change to derive paths from kernel.project_dir when available removes a class of hardcoded absolute path assumptions and makes container/deploy-time path drift less likely — a genuine integration-quality improvement for Symfony 3+ projects.

Technical risk. Three items in this release carry behavior risk rather than feature risk:

1. "Wait for supervisord by default" is a default-behavior change. Any automation that previously issued control commands optimistically and tolerated supervisord being unavailable will now block or fail-fast differently. This is the item most likely to surface in CI and deploy pipelines.
2. "Group consumers so supervisor sends signals in parallel" changes shutdown/restart semantics. Previously signals were likely delivered per-program serially; now a group signal fans out. That reduces restart time but converts a staggered drain into a synchronized one, with direct consequences for queue reconnect storms and in-flight message handling.
3. kernel.project_dir fallback is low risk but introduces environment-conditional path resolution — behavior will differ between Symfony 3+ and older/standalone contexts, which is a support-matrix and reproducibility concern. No deprecations or removals are signaled, and the release is a minor bump, so there is no hard breaking change; risk is concentrated in undocumented defaults.

Key questions.

• Is the consuming application Symfony or Laravel? If Laravel, is this package being evaluated as a Supervisor config generator only, and is that worth the dependency?
• Does "wait for supervisord by default" have an opt-out flag, and what is its name and default in 3.2.2 versus 3.3.0?
• What is the maximum simultaneous-consumer count in our deployments? Parallel group signaling at that scale may exceed RabbitMQ connection or channel limits.
• Are consumers idempotent and tolerant of abrupt SIGTERM during message handling? Parallel signaling shortens the drain window.
• What Symfony and PHP versions are supported by 3.3.0, and does the maintainer publish a support matrix?
• What is the release cadence and maintainer count? This is a low-activity, effectively single-maintainer package — bus factor is the dominant long-term risk.

Integration Approach

Stack fit. Confirm the framework boundary before any planning. On Symfony 3+/4 with php-amqplib or Symfony Messenger consumers, the bundle fits cleanly: it owns process definition, the application owns message handling. On Laravel, do not integrate; instead reuse the generated Supervisor program shape as a template or standardize on Horizon. On mixed estates, treat the bundle as a Supervisor-config artifact producer and keep it out of the request-serving application's dependency graph.

Migration path. From 3.2.2, upgrade is a composer constraint bump plus regeneration and review of the Supervisor config. The critical step is a config diff: capture supervisorctl output or the generated .conf files before and after, and confirm whether programs are now emitted inside a [group:X] stanza. If groups appear, verify supervisorctl restart X:* and stop/start semantics against existing runbooks and deploy scripts. Pin 3.2.2 in the lockfile until that diff is understood.

Compatibility. Validate against the actual Supervisor version in production — group semantics and supervisorctl group syntax are version-sensitive, and older Supervisor releases handle group signals differently. Also pin the Symfony minor version, since the kernel.project_dir branch is conditional. Run the upgrade in a staging environment with the real consumer count, not a single-worker smoke test.

Sequencing. (1) Confirm framework and confirm opt-out flags for the wait behavior. (2) Upgrade in a non-production environment and diff generated configs. (3) Load-test restart and deploy with production-representative consumer counts to size the parallel-signal effect. (4) Update deploy scripts and runbooks for the new wait semantics. (5) Roll to production during a low-traffic window with a documented rollback to 3.2.2.

Operational Impact

Maintenance. Low. The package is a thin config generator; there is little surface area to maintain. The real maintenance burden is the pinned Supervisor version and the Symfony compatibility branch, both of which the team now owns implicitly.

Support. Weak. Small maintainer base, and the 3.3.0 notes are terse — the "wait for supervisord by default" change has no stated rationale or opt-out documentation in the changelog. Budget for reading the diff directly rather than relying on release notes or community answers.

Scaling. Parallel group signaling improves restart and deploy latency, which is the release's main operational win, and it scales favorably with consumer count on the time axis. It scales unfavorably on the contention axis: all consumers reconnect to RabbitMQ within the same window, which can produce connection-churn spikes, re-queue storms, and temporary consumer-count collapse. At high consumer counts, consider splitting into several smaller groups rather than one large group.

Failure modes. Watch for: (a) deploy pipelines hanging or failing when supervisord is unreachable under the new default wait behavior; (b) synchronized restarts overwhelming the broker or exhausting file descriptors; (c) messages redelivered en masse if consumers are killed mid-ack; (d) path resolution differences between environments due to the conditional kernel.project_dir branch, producing configs that work locally and not in containers; (e) a partially signaled group leaving some consumers running and others stopped, producing uneven queue consumption.

Ramp-up. Low for an engineer already fluent in Supervisor and RabbitMQ; moderate for one who is not, because the bundle hides the Supervisor config that actually governs behavior. Ramp-up cost is dominated by learning the generated config and the signal semantics, not the PHP API. Plan a half-day of review plus one staging restart drill before production rollout.