Symfony Process Manager Laravel Package

Technical Evaluation

Architecture fit. v0.0.2 is a domain-model change, not a cosmetic config rename. The package is moving from a transport-centric to a consumer-centric architecture: the consumer becomes the unit of scaling, lifecycle accounting, and log correlation, while transport is demoted to a message-flow attribute. That is the right model for anything running an autoscaler (you scale workers, not queues), but it means every artifact that assumed "transport == worker" — config, dashboards, alerts, runbooks — is now coupled to a concept that no longer exists in the same form.

Integration feasibility. The mechanical work is small: rename the root config key, wrap one or more transports under a consumer, re-import the bundled dashboard. The real cost is that the change touches three separate planes at once (application config, metrics contract, alerting/SLOs), and the metrics plane is the expensive one.

Technical risk.

• Config rename without a deprecation shim is the loud risk — and loud is good. The question is whether the package fails at boot or silently ignores the old transports: key; a silent ignore in a v0.0.x package would be a production incident waiting to happen.
• Metric label changes are the quiet risk. Removing transport from lifecycle counters will not error — PromQL queries and Grafana panels pinned to transport simply return no data. Silent zero-valued dashboards and dead alerts are materially worse than a failed deploy. This is the single highest-risk item in the release.
• Multi-transport drain semantics are a new footgun. List order = priority, so [main, failed] deliberately starves the fallback. Teams will reasonably assume "list = fan-out/fair share" and instead build head-of-line blocking into their worker. The release notes say this plainly, but it is the kind of semantic that gets misread.
• Autoscaler gauges emitted at start() is a genuine fix — empty template variables and Fixed-strategy pools with zero visibility until first tick were real operational blind spots — but it changes scrape-timing expectations and should be validated against existing alert for: durations.

Key questions for the maintainer / to resolve in a spike.

1. Does v0.0.2 fail loudly on a leftover transports: root key, or ignore it?
2. Is there any dual-emit or transitional period for both {transport} and {consumer} labels, or is this a hard cutover?
3. Under multi-transport consumers, what is the autoscaler's denominator — aggregate backlog across all listed transports, or per-transport? How does unmet_demand behave when the primary is saturated and the fallback is idle?
4. Does worker_busy_workers aggregate across a consumer's transports, and if so does busy mean "busy on any transport"?
5. Is backoff/worker_backoffs_total applied per consumer or per transport when one transport holds a poison message?
6. What are the supported Laravel / PHP / Symfony Messenger / Prometheus-client version ranges, and is there any semver commitment for 0.0.x?
7. Is getReceiverName() stable across retries and redeliveries, so the retained transport label on messages_processed_total is trustworthy?

Integration Approach

Stack fit. This is an additive worker-layer component, not a queue replacement. If the platform already runs Symfony Messenger under Laravel, this is a config-plus-dashboards upgrade. If the platform is on Laravel's native queue drivers (Redis/SQS/database), this is only relevant if there is an active or planned move to Messenger — evaluate it as part of that decision, not on its own.

Migration path (per environment).

1. Snapshot first. Export current Grafana dashboards, alert rules, and any PromQL in code, so the "before" is diffable after cutover.
2. Config restructure for parity. One consumer per existing transport, one transport per consumer. Resist consolidating into multi-transport consumers during the migration commit — change the model and the topology separately.
3. Staging soak with both dashboards. Import the new bundled dashboard alongside the retained old one and compare panels side by side for a full traffic cycle, including a failure injection to exercise worker_exits_total{consumer, exit_code}.
4. Deliberate consolidation, later. Move to multi-transport consumers only where priority semantics are actually wanted ([main, failed]), and give genuinely fair-shared work its own consumer.
5. Alert cutover. Rewrite rate() expressions and thresholds against consumer; re-baseline thresholds since label cardinality and aggregation change the numbers.

Compatibility checks before committing. Pin the exact version — a 0.0.x line with a breaking config rename on a point bump carries no upgrade safety. Verify the /metrics endpoint contract (path, port, scrape interval) against existing scrape config, confirm the Prometheus client version, and confirm the new start() gauge emission does not race the first scrape.

Sequencing. Config rename and dashboard swap must land together in the same change window (the label change forces it), but the dashboard should be prepared and validated in staging beforehand. Rollback is a full revert of both config and dashboards — there is no partial state that works. Budget a short dual-dashboard period rather than an instantaneous delete of the old one.

Operational Impact

Maintenance. Treat the metrics label contract as the primary coupling surface between this package and the observability stack. Dashboards and alert rules should live in the same repo as the worker config so a future rename is a single PR, not a cross-team scavenger hunt. Expect continued churn: pre-1.0 releases have already shipped one breaking config change, so plan a review per release rather than a set-and-forget upgrade.

Support. On-call runbooks must be rewritten around consumer — the current triage questions ("which transport is backed up?") no longer map to the lifecycle counters. Keep messenger_messages_failed_total{transport, message_class} as the documented escape hatch for transport-level failure visibility; it is now the only place transport survives in the metrics contract. The [worker N consumer-label] log prefix and extra.consumer JSON context are a real support win — log, metric, and config now share one key.

Scaling. Consumer is the unit of scale, which is cleaner for the autoscaler but concentrates risk: a single consumer spanning several transports scales as one pool, so a hot primary and a cold fallback cannot be sized independently. Watch series cardinality — worker_exits_total{consumer, exit_code} multiplies consumers by exit codes, and a consumer-per-transport topology (the fair-sharing pattern) multiplies consumers again. The start() gauge emission is a clear improvement for Fixed-strategy pools and for anything that builds Grafana template variables from the metric store.

Failure modes to instrument against.

• Metric rename missed in one dashboard or alert → silent zeros, no paging. Highest likelihood, highest mean-time-to-detect.
• Multi-transport list used where fair sharing was intended → starved transport, growing tail latency, no obvious error signal.
• Poison message on one transport inside a multi-transport consumer → head-of-line blocking for all transports in that consumer if backoff is consumer-scoped.
• Exit-code label explosion → Prometheus memory pressure from a misbehaving worker loop.
• Alert thresholds carried over unchanged from transport to consumer aggregation → either flapping or muted alerts in the first days.

Ramp-up. The conceptual shift engineers must absorb is consumer-vs-transport, and specifically that priority ordering is a deliberate starvation policy. For a team already on Messenger, this is a half-day of reading plus a migration; for a team new to Messenger, budget two to three days including the metrics model. The improved log context and the bundled dashboard re-import do most of the onboarding work — the dashboard is effectively the documentation for the new model, so re-import it rather than patching the old one.