Symfony Process Manager Laravel Package

Product Decisions This Supports

• Worker topology and failover design. The new consumers: model lets one consumer declare multiple transports: (scalar or list), with list order as priority order. A PM can now standardize a [main, failed] pattern for primary/fallback draining in a single worker pool instead of standing up a separate pool per transport — a direct cost and operational-complexity decision for queue architecture.
• Autoscaling and capacity policy. AutoscalerLoop now emits pool gauges (autoscaler_target_workers, autoscaler_current_workers, autoscaler_unmet_demand, worker_busy_workers) at start(), so Fixed-strategy pools and freshly booted workers are visible immediately. This makes autoscaler behavior observable from the first second, supporting decisions about whether to trust autoscaling in production or keep static worker counts.
• Build vs. buy for queue orchestration. The package bundles consumption, autoscaling, metrics, and dashboards. That is a candidate replacement for in-house worker supervisors or for extending a managed-queue setup, and the decision should weigh the bundled Grafana asset and Prometheus contract as part of the product surface, not just the worker process.
• Observability contract and SLO design. Metric labels changed from {transport} to {consumer} on lifecycle counters (worker_starts_total, worker_failures_total, worker_backoffs_total, worker_exits_total) to avoid inflating rate() queries by transport-list length. Per-transport health remains available via messenger_messages_failed_total{transport,message_class}. This is a deliberate cardinality vs. granularity trade-off that product and SRE should agree on, because it defines what alerts and dashboards can be built.
• Dashboard/UX decisions. The bundled dashboard is a product artifact: the $transport template variable becomes $consumer, and panels were reflowed. Re-importing is a user-facing migration step that affects anyone who built workflows on the old dashboard.
• Roadmap sequencing. The 0.0.1 → 0.0.2 jump contains breaking config and metric changes. A PM should sequence adoption behind a version-pinning and dashboard-migration workstream rather than treating this as a drop-in utility upgrade.

When to Consider This Package

Consider it when:

• You run Laravel/PHP queue workers and want autoscaling plus Prometheus metrics without building a supervisor and metrics layer yourself.
• You already operate Prometheus + Grafana and want a bundled dashboard as a starting point.
• You need priority/failover draining across transports (e.g. [main, failed]) without multiplying worker pools, and can accept that priority order is list order.
• You want consumer-level lifecycle metrics with bounded cardinality, and transport-level failure detail via messenger_messages_failed_total.
• Your platform team is small enough that consolidating worker orchestration into one package is a net win, and you can pin versions and absorb pre-1.0 breaking changes.

Look elsewhere when:

• You require a stable configuration and metric schema. Renaming transports: to consumers: and relabeling lifecycle counters in a 0.0.x release signals the public contract is still moving; if downstream dashboards are customer-facing or contractually pinned, wait for 1.0 or vendor a fork.
• You are standardized on a managed queue with platform-native autoscaling (e.g. cloud queue + serverless consumers); this package duplicates that control plane.
• You already rely on Laravel Horizon or an equivalent first-party dashboard/autoscaling stack and do not want two overlapping worker-management surfaces.
• You need per-transport fan-out on lifecycle counters for existing queries. That fan-out was intentionally removed; migrating pinned queries to {consumer} is mandatory, and if you cannot rework those queries, this release is not adoptable as-is.
• You do not run Prometheus/Grafana; the metrics and dashboard investment is the core value proposition.
• You need fair sharing across transports rather than priority draining — the release explicitly says to give each transport its own consumer for fair sharing, so the feature does not cover that case.

How to Pitch It (Stakeholders)

For executives: This package turns queue worker operations into a managed, observable capability: autoscaling decisions are visible immediately at startup, one worker pool can drain primary and fallback transports in priority order, and lifecycle metrics are deliberately bounded so dashboards and rate() queries stay fast as transport lists grow. The trade-off is maturity — v0.0.2 ships breaking config and metric changes, so adoption should be scoped as a pinned-version pilot with a dashboard migration, not a company-wide standard yet.

For engineering: Expect a short but mandatory migration: rename transports: to consumers: in bundle config, migrate Grafana/Prom queries pinned to the transport label on worker lifecycle counters to consumer, and re-import the bundled dashboard ($transport → $consumer, panels reflowed). Transport-level failure visibility is preserved via messenger_messages_failed_total{transport,message_class}; do not expect per-transport fan-out on start/failure/backoff/exits counters. Worker logs now use [worker N consumer-label] with extra.consumer in JSON context, which simplifies log-based debugging by consumer.

For product/ops: The multi-transport consumer is the headline capability — encode [main, failed] as the standard pattern for failover, and reserve separate consumers for workloads that need fair sharing. The autoscaler gauge fix eliminates the cold-start blind spot that made Fixed-strategy pools and Grafana template variables look broken; verify /metrics is populated at worker start as an acceptance criterion. Given the pre-1.0 churn, treat the metric and config schema as an internal interface to pin and review each release, and budget migration effort for any dashboard consumers outside the platform team.