Laravel Queue Worker Laravel Package

Technical Evaluation

Architecture fit. The package bridges a queue hub and satellite Laravel environments by spawning each job as a child process via Symfony Process. That is a coarse, process-per-job integration boundary: strong isolation (each environment keeps its own dependencies, code, and database), weak throughput and latency. 1.3.0 does not change the boundary; it corrects lifecycle semantics that were previously wrong.

Integration feasibility. Feasible, but it is a fleet-wide, multi-party change, not a single composer update on the hub:

• Every environment must resolve jeffersongoncalves/laravel-queue-consumer to ^1.2. ^1.1 permits 1.2.0 but does not require it, so committed composer.lock files will happily stay on 1.1.x.
• The hub’s default queue connection retry_after must exceed the longest declared environment timeout plus 60 seconds, or jobs are rejected at dispatch.
• Clients that send timeout: 0 (Laravel’s “no timeout”) now receive 422 and must change.

Technical risk.

• Behavior change in a minor release. timeout: 0 and negative timeouts move from silently running for one second to a hard 422. Any API consumer relying on the old semantics breaks at deploy. This is semver-questionable for 1.3.0 and should be treated as a client-facing breaking change.
• retry_after gate is a configuration landmine. With Laravel’s default retry_after of 90 seconds, the maximum accepted timeout is under 30 seconds. Deployments using long-running jobs will start refusing work at POST /api/jobs until configuration is raised. The rejection message names both numbers, which helps, but the failure mode is dispatch-time and affects all new jobs.
• Pre-upgrade queued payloads. The worker’s alarm reads timeout from the outer queue payload already in Redis and cannot be rewritten, so the 60-second margin is deducted from the child’s share. A job queued before the deploy with timeout at or below 60 seconds yields a zero or negative child timeout. The release notes do not describe clamping for this case; behavior is undefined from the outside.
• Outdated-consumer detection is string-matched on stderr. Localized Symfony output, a different Symfony major, or an argument-parser message change will evade detection and degrade back to the original opaque failure.
• Orphan risk is narrowed, not eliminated. Symfony now kills the child on child-timeout, but if the hub worker dies outside pcntl_alarm (OOM, deploy restart, SIGKILL) there is still no documented process-group cleanup.

Key questions.

• What are the supported PHP, Laravel, and Symfony version ranges, and which queue connections are supported beyond the default Redis path? SQS uses visibility timeout, not retry_after, and the ordering advice does not obviously translate.
• Is there clamping, rejection, or defined behavior for a pre-upgrade queued payload with timeout ≤ 60?
• Is timeout optional in the payload, and what default applies? Is there an enforced maximum?
• Are children killed as a process group, or is a lingering grandchild possible after a parent timeout?
• Does the retry_after validation check the connection actually used by the job, or only the default connection?
• Are there plans to localize-proof or version-pin the outdated-consumer detection?

Integration Approach

Stack fit. Assumes Laravel queues with a Redis (or Redis-like) default connection whose retry_after is a rewritable configuration value. Strong fit if the hub owns a single default queue connection; weaker if jobs route across connections with independent retry_after or visibility semantics.

Migration path.

1. Inventory all environments and their resolved laravel-queue-consumer version; commit ^1.2 and update locks.
2. Compute the maximum declared timeout across environments; set hub retry_after above that plus 60 seconds.
3. Drain the hub queue before deploying 1.3.0 to avoid the legacy-payload margin path entirely.
4. Deploy hub 1.3.0.
5. Update API documentation and clients: timeout: 0 is no longer valid; timeouts must be explicit and bounded.

Compatibility. Payload shape is otherwise unchanged from 1.2.0. Environments on consumer <1.2 already fail against the --queue flag introduced in 1.2.0; 1.3.0 only replaces the cryptic Symfony message with a typed exception, so it does not fix an outdated fleet—it diagnoses one. Treat consumer upgrades as a prerequisite, not a follow-up.

Sequencing. Configuration (retry_after) first, environment consumer upgrades second, queue drain third, hub deploy fourth, client and documentation updates last. Do not deploy the hub before retry_after is verified, or dispatch starts returning 422 immediately.

Operational Impact

Maintenance. Active maintenance is visible in the issue references and the quality of the release notes, but release discipline is a concern: behavior changes shipped in a minor version without a deprecation window. Pin exact versions on the hub and automate environment dependency updates (Renovate/Dependabot) so the composer.lock drift does not recur. Expect the fleet-wide consumer upgrade to be recurring toil.

Support. The new OutdatedEnvironmentConsumerException is a genuine support improvement: it names the environment slug, its path, and the exact composer require line, which collapses a previously cross-package triage into a single action. The new 422 responses are a new support surface and need an error catalogue covering the timeout, retry_after, and outdated-consumer cases. Other failures still surface raw Symfony messages.

Scaling. Process-per-job caps throughput at hub worker count divided by job duration. Worst-case worker occupancy grows by the 60-second margin because the hub job retains the extended timeout while the child runs; size the worker pool against p95 duration plus margin, not average. There is no connection pooling or warm process reuse; spawn overhead is fixed per job.

Failure modes.

• Dispatch-wide 422 if retry_after is left at its default with long-declared timeouts.
• Short-timeout jobs sitting in the queue across the upgrade getting a reduced or non-positive child timeout.
• Outdated consumer not detected due to stderr string drift, reverting to opaque failures.
• Orphaned child processes on worker death outside the alarm path.
• Double execution is mitigated by the dispatch-time retry_after check, but only for connections and code paths where that check actually runs.

Ramp-up. Moderate. Operators need a written runbook for the retry_after math, environment consumer version, and queue-drain ordering; developers need to stop emitting timeout: 0 and start declaring explicit upper bounds. A canary environment plus a staging job pinned at the maximum timeout is the cheapest way to confirm the child actually times out before the worker alarm.