Resque Bundle Laravel Package

Technical Evaluation

Framing correction comes first, because it changes every downstream decision. shonm/resque-bundle is a Symfony bundle, not a Laravel package, despite how it was surfaced in this catalog. It wires chrisboulton/php-resque — a PHP port of Ruby Resque — into a Symfony 2/3-era container via AppKernel registration, YAML service definitions, and app/console commands. There is no Laravel seam to bind to: no bundle loader, no YAML container config, a different console kernel, and different event contracts. A TPM evaluating this as a Laravel dependency should treat the catalog entry itself as a data-quality defect and file it accordingly. That ticket is arguably higher-value than any conclusion about the package.

Architecture fit — not a fit; treat as a reference artifact. The only defensible architectural role for this package is as a map of a legacy Resque integration: job class conventions, queue naming, DI wiring, worker lifecycle, failure backend. That is a documentation use, not a dependency use. Adopting it means owning a fork of an unmaintained wrapper around an unmaintained engine.

Where a TPM actually extracts leverage:

• Build-vs-buy evidence. A self-declared "not maintained" description, 12 stars, and 0 dependents is the cleanest possible written justification for standardizing queueing on first-party tooling (Horizon for Laravel, Messenger for Symfony). Record the rejection explicitly in the dependency register so it isn't relitigated next quarter.
• Legacy migration scoping. If any part of the estate still runs Symfony 2/3 on php-resque, this bundle bounds the migration surface: job inventory, payload format, queue names, retry policy, worker fleet. That is the input to an effort estimate, and the estimate is the deliverable — not the adoption.
• Observability roadmap trigger. Resque ships no dashboard, no metrics, no dead-letter UI, and the bundle adds none. That forces an explicit roadmap decision (build a Horizon-equivalent or accept blind queue operations) instead of leaving it as a footnote in an incident postmortem.
• Correct reading of the 0.86 "opportunity" score. It signals an underserved niche — no credible maintained Laravel-native Resque-compatible option — not a good buy. The correct response to whitespace is owned tooling, not an abandoned wrapper.

Technical risk — high, and concentrated in the transitive chain rather than the bundle itself. The exposures a TPM must put on the risk register:

• Unmaintained chain. Bundle unmaintained; php-resque unmaintained; no PHP 8.x commitment; no security patch path; no vendor to escalate to.
• Delivery guarantee gap. Classic Resque pops the job before execution. A worker killed mid-job loses the job — no ack, no visibility timeout, no redelivery. Any at-least-once requirement fails this design outright.
• Process model. Fork-per-job depends on pcntl and POSIX signals, which is fragile or unavailable under common FPM, container, and managed-runtime setups.
• Payload coupling. PHP-serialized job objects mean refactoring a job class breaks already-enqueued entries — a hard constraint on deploy sequencing.
• No built-in retries, scheduling, unique jobs, or UI. All require plugins from a thin, largely abandoned ecosystem.

Key questions before any decision (each with a named owner):

1. Is the requirement asynchronous execution in Laravel, or interoperability with existing Ruby Resque queues? The answer flips the recommendation entirely.
2. Do production Resque queues and workers exist today, and which team owns them?
3. Is cross-language payload compatibility required in either direction?
4. What is the reliability bar — is job loss on worker crash tolerable, or is at-least-once mandatory?
5. Is pcntl/fork available in the target runtime?
6. Who is the named maintainer with funded capacity if we fork?

Integration Approach

Stack fit. For Laravel, the correct target is the native queue with the Redis driver plus Horizon for supervision, metrics, retries, and a failed-job UI — same capability, maintained dependency chain, zero contribution from this bundle. For Symfony 4+, it is Messenger. This package fits neither modern target.

Migration path (Symfony/Resque → Laravel native). Sequence, with a gate between each step:

1. Inventory every job class, payload shape, queue name, retry policy, and schedule. This is the true cost driver; scope it before writing code.
2. Reimplement each as a ShouldQueue job; replace Resque::enqueue call sites with dispatch(). Payloads move from PHP serialization to JSON — a strict improvement for deploy safety.
3. Dual-run behind a feature flag for a bounded window; drain legacy workers to zero; verify parity on a representative job sample.
4. Decommission the bundle, php-resque, and the worker fleet in one step.

Interop path (must talk to an existing Ruby Resque deployment). Do not adopt the bundle. Build a small owned adapter that writes Resque-compatible Redis payloads (JSON class/args envelope into resque:queue:<name>) and consume with a dedicated worker. Scope this as a one-to-two sprint spike plus ongoing ownership; the surface is small and well-documented — which is exactly why carrying an abandoned bundle instead is a bad trade.

Compatibility checks before any code. Validate PHP version support against the fork's composer.json (Symfony 2/3-era code is unlikely to be PHP 8.x clean); confirm Redis version assumptions (Resque predates Redis 6 ACLs and auth changes); confirm fork availability in the runtime; freeze the PHP-serialized payload format as an interface for the duration of any parallel run.

Gates and decision rights. Gate 1 is the only one that matters initially: requirement clarified as native queue vs. interop, with an explicit decision owner named. Gates 2–4 (inventory complete, adapter or job-port spike green in staging with realistic payloads, dual-run with parity evidence) are engineering-owned checkpoints. A TPM should not let the team past Gate 1 without a written decision — this is a build-vs-adopt call, not a dependency upgrade.

Governance note. If a frozen Symfony app genuinely must keep working, the acceptable pattern is fork-and-vendor with a named maintainer, a frozen PHP version, and no security-patch SLA expectation. Anything short of that is unowned risk.

Operational Impact

Maintenance. Effectively zero upstream. Adoption means forking and owning permanently: tracking PHP minor-version breakage, Redis client behavior changes, and security issues in a dependency nobody is watching. Budget it as a recurring, low-volume but non-zero tax with no escalation path.

Support. No vendor, no maintainer, no community — 12 stars and 0 dependents means no Stack Overflow corpus, no issue history to mine, and no peer organizations to compare notes with. Every incident is debugged from source. This is the largest hidden cost and should be stated plainly in any stakeholder memo.

Scaling. Horizontal scaling by adding workers is straightforward in principle. The real constraints are forked-worker memory growth with no default recycling, Redis as a single point of failure and a hot connection target under high poll rates, and blocking-pop connection management. None are insurmountable; all require bespoke tooling that Horizon provides out of the box. A TPM should cost this as engineering time, not as a line item.

Failure modes requiring compensating controls the package does not supply:

• Silent job loss on worker crash between pop and completion — no ack, no redelivery. Control: idempotency and reconciliation jobs.
• Poison jobs looping with no retry cap or dead-letter queue. Control: retry wrapper plus alerting on queue depth and age.
• Payload deserialization failures after any job-class refactor. Control: deploy-time queue drain and a frozen payload contract.
• Fork instability where pcntl is disallowed, presenting as workers that start and immediately exit. Control: supervisor restart policy and runtime preflight checks.
• Redis unavailability stalling all workers with no graceful degradation. Control: circuit-breaking enqueue paths and explicit degradation behavior.
• Zombie workers after deploy with no supervisor-level reconciliation. Control: pidfile hygiene and supervised process groups.

Ramp-up. The mental model is Resque's, not Laravel's: Redis key layout, fork-per-job lifecycle, signal-based worker control. Engineers fluent in Laravel queues will not transfer cleanly, and the learning material is thin. Expect meaningful onboarding friction on a component with no forward path — a real cost when the same engineers could be learning Horizon in an afternoon.

Bottom line for the portfolio. Do not adopt for new Laravel work: unmaintained, framework-incompatible, and carrying genuine delivery-guarantee and support deficits. The only defensible use is short-lived interoperability with an existing Ruby Resque deployment, and even then the right move is a small owned adapter with a defined exit plan. The TPM deliverables here are a documented no-go, a scoped migration estimate, an observability roadmap decision, and a catalog data-quality ticket — not a dependency.