Resque Bundle Laravel Package

Technical Evaluation

Architecture fit — primary blocker. The package is a Symfony2 bundle, not a Laravel package. It ships a Bundle subclass, a DI container extension, and console commands wired through Symfony's Kernel/ContainerAwareCommand. Laravel has no bundle registration mechanism; the package cannot be composer required into a Laravel app and expected to boot. Only the underlying transitive dependency — chrisboulton/php-resque — is framework-agnostic and reusable. The assessment prompt frames this as a Laravel/PHP package; treating that framing at face value would be the first and most expensive mistake a TPM could make here.

Integration feasibility. Effectively zero for Laravel as-is. A Laravel integration would mean writing a service provider, config file, and queue driver wrapper around raw php-resque — i.e., the bundle contributes nothing and you inherit only the maintenance burden of its pinned, stale dependency graph. For a Symfony2 application still in service (rare but not impossible), the bundle is a thin convenience layer over php-resque and would integrate with modest effort — though you would be adopting Symfony2-era service definitions and container idioms.

Technical risk. High and largely unmitigated:

• EOL platform. Symfony 2.x reached end of life in November 2018. Any bundle targeting it inherits an unsupported framework baseline with no security patch path.
• PHP 8 incompatibility (probable). Symfony2-era code commonly relies on each(), create_function, non-typed container signatures, and dynamic properties — all removed or deprecated in PHP 8. Expect fatal errors on modern runtimes. Must be verified, not assumed.
• Abandonment signals. 4 stars, 0 dependents, score 0.14. The 2021-11-30 release date is almost certainly a metadata/tag artifact rather than evidence of active maintenance — the codebase predates it by years. There is no credible security-response channel.
• Forking worker model. php-resque forks a child per job. In any Laravel context this means inherited PDO connections, open file handles, and container state across the fork boundary — a well-known source of duplicate-consumption and stale-connection bugs that must be handled with explicit reconnect logic.
• Supply-chain surface. Unmaintained transitive dependencies with no patch cadence.

Key questions for the team.

1. Is the actual requirement "background jobs on Redis," or specifically "Resque wire-compatibility" (e.g., interoperating with existing Ruby Resque workers or resque-web)?
2. Are we targeting Laravel or a legacy Symfony2 app? If Laravel, why is this package in the candidate set at all?
3. What PHP version must be supported? Anything ≥ 8.0 likely disqualifies the bundle outright.
4. Do we need delayed jobs, retries with backoff, rate limiting, or job dashboards? The bundle provides none of these natively.
5. What is the appetite for owning a fork of an unmaintained bundle versus adopting a maintained queue layer?

Integration Approach

Stack fit. Poor for Laravel, marginal for Symfony2. The correct decomposition is: discard the bundle, evaluate chrisboulton/php-resque directly (still low-activity, so evaluate with the same skepticism), and compare against the native option. For Laravel, the native Redis queue driver plus Horizon delivers the same underlying model — Redis-backed lists, multiple named queues, supervised workers — with first-class framework integration, retries, backoff, metrics, and a UI. Unless Resque wire-format compatibility is a hard external constraint, the native path dominates on every axis.

Migration path. Three viable routes, in descending order of preference:

1. Laravel native queue + Horizon. Zero new dependencies, supported, observable. Requires rewriting job payloads into Laravel Job classes — mechanical if job count is small.
2. php-resque direct, framework-agnostic wrapper. Choose only if Resque compatibility is contractual. You own the wrapper, the supervisor config, and the fork-safety code.
3. Adopt the bundle. Justified only inside an existing Symfony2 application with no modernization budget. Treat as a stopgap with a dated exit.

Compatibility. Assume PHP 5.6–7.x and Symfony 2.3–2.8 until proven otherwise. Before any commitment, run a throwaway spike: install on the target PHP version, boot the container/console command, enqueue and process one job. This is a half-day experiment that resolves most of the open risk. Check the bundle's composer.json constraints against the app's locked dependency graph — a conflict there ends the evaluation immediately.

Sequencing. (a) Confirm the actual requirement and rule out Resque wire-compatibility early; (b) spike the bundle on the target runtime to establish PHP/Symfony compatibility facts; (c) benchmark native queue against php-resque on the real job mix — throughput, retry semantics, failure handling; (d) make a build-vs-adopt decision with the fork-safety and observability gaps priced in; (e) if adopting, isolate behind an internal queue interface so the eventual swap is a driver change, not a rewrite.

Operational Impact

Maintenance. You will own this code. Zero dependents and negligible community means no upstream fixes for PHP upgrades, Symfony upgrades, or Redis protocol changes. Budget ongoing engineering time for a fork, or accept a frozen runtime. The bundle should be treated as vendored source, not a dependency.

Support. No vendor, no active maintainer, no security disclosure process. Internal on-call must absorb queue-layer incidents. Compare against Horizon, where failure inspection, retry, and worker status are built in; here, operational visibility means shell access to Redis and log tailing, or standing up Ruby resque-web — an unwelcome second runtime.

Scaling. The model itself scales acceptably: Redis lists, N worker processes, horizontal scale by adding workers. What does not scale is operational maturity — no autoscaling hooks, no per-queue concurrency controls, no rate limiting, no native delayed jobs, no backpressure signals. Capacity planning is manual. Memory is the sharper constraint: forking workers grow over long runs, so worker recycling (max-jobs-per-child) is mandatory and must be configured deliberately.

Failure modes. Enumerate these before go-live:

• Fork-boundary state leakage — stale DB connections in children; requires explicit reconnect after fork.
• Silent job loss — Redis without persistence (AOF/RDB) loses in-flight and queued jobs on restart.
• Poison jobs — no native exponential backoff; a failing job can hot-loop and starve a queue.
• Orphaned workers — no supervisor by default; a crashed worker leaves jobs unprocessed with no alert.
• Unbounded failure queue — failed jobs accumulate with no retention policy or replay tooling.
• PHP runtime drift — a base-image upgrade silently breaks the worker; pin the runtime.
• No idempotency contract — at-least-once delivery means every job must be written idempotent; this is a design obligation on the team, not a package feature.

Ramp-up. Low conceptual cost — the Resque model (queues, workers, perform()) is simple and well documented. The real ramp-up is in the sharp edges: fork safety, Redis durability configuration, supervisor setup, and failure triage without a dashboard. Estimate one to two engineer-weeks to reach production confidence, versus roughly one to two days for Laravel's native queue with Horizon already understood.

Bottom line. For a Laravel stack, this package fails the architecture-fit test before any other criterion is evaluated and should be removed from the candidate set. The defensible use case is narrow: an existing Symfony2 application that needs a stopgap and has a funded modernization plan. Even there, wrapping php-resque directly is cleaner than adopting an unmaintained bundle.