Resque Laravel Package

Technical Evaluation

Architecture fit

glit/resque is a PHP port of Ruby's Resque. Jobs are serialized as JSON and pushed onto Redis lists (resque:queue:<name>); long-lived worker processes BRPOP those lists and execute a perform() method on a job class. The fork's only differentiator is a pluggable job-instantiation delegate, so job objects can be resolved from a container (the README cites Symfony2's DIC) instead of being new'd reflectively. That makes it a plain Redis list queue with process-forked workers — not an event bus, not a scheduler, not a workflow engine.

Fit is narrow: a legacy PHP monolith (PHP 5.6–7.x, Symfony 2.x/3.x era) that already has Redis, already runs chrisboulton/php-resque-style workers, and wants container-managed jobs without rewriting its worker layer. It is a poor fit for a Laravel application, where the native queue (Redis driver + queue:work, Horizon for observability) delivers the same semantics with maintained code and first-class retries, backoff, and timeouts. Adopting this package means running two queue paradigms and owning an unmaintained dependency to gain a feature Laravel already ships by default.

Fit decision, stated as a TPM would: this is a legacy-life-support artifact, not a platform choice.

Integration feasibility

Mechanically simple: Composer install, a Redis connection, a worker entrypoint script, and job classes implementing a perform() contract. The job-factory hook is small (typically instantiate($className, $args)), so wiring it to Laravel's container is trivial. The friction is the environment contract, not the API:

• pcntl and posix are required for the forking worker — unavailable on Windows, frequently disabled in hardened FPM/base images. This is a container-image and platform-approval item, not a code item.
• Job arguments must be JSON-serializable: no closures, no binary payloads, no object round-tripping without an explicit serializer.
• The worker is a supervisor/systemd-managed daemon, not an artisan command — a deployment-topology change and a new thing to put in the runbook.

Documentation credibility flag (material). The package description bills this as a "Laravel integration" with a service provider, publishable config, and worker commands. The repository (glit/php-resque) is a Resque port whose enhancement is a Symfony2-era DIC delegate. Treat the description as aspirational marketing until a spike proves the service provider and artisan commands actually exist. A package whose own front-page claims outrun its code is an execution risk before a single line is written.

Technical risk

High, driven by project health rather than code quality. Zero stars, zero dependents, score 0 mean: no downstream users to surface bugs, no compatibility PRs, no CVE triage, bus factor of one. The lineage is almost certainly PHP 5/7-era, so expect deprecation noise and latent breakage on 8.1+ (dynamic properties, ${var} interpolation, each()).

Supply-chain risk is non-trivial: an abandoned, low-traffic Packagist namespace is a takeover candidate. Installation must be pinned by commit hash from a vendored/private mirror, never ^-floated from upstream.

Semantics risk is the one that bites product. Resque is at-least-once with a visibility gap: a job popped and killed before being recorded as in-progress is silently lost; a crash mid-execution strands the job in the in-progress registry with no automatic requeue. There is no native retry, no delayed/scheduled jobs, no uniqueness, no rate limiting, no dead-letter queue. All of these become our code, and every one of them is work the framework-native option gives us for free.

Key questions

1. Which upstream is this forked from, at what commit, and what is the delta beyond the job factory?
2. What PHP range and extensions does composer.json actually declare — has anyone run it on 8.x?
3. Is the job-factory interface stable and documented, or an undocumented hook we'd reverse-engineer?
4. Does it support Redis AUTH/TLS/SELECT index, and does it use ext-redis or Predis, at what client version?
5. What is the crash-recovery story — in-progress pruning, dead-worker detection, requeue tooling?
6. Are we prepared to fork this into a private repo and own it, or is it a stopgap while we migrate off?
7. Governance: does the description's Laravel framing survive contact with the code? Answer before any roadmap commitment.

Integration Approach

Stack fit

Only justified for a legacy Symfony2/DIC monolith on PHP 7.x with an existing Resque worker fleet. There the fork buys exactly one thing — container-injected jobs — worth having if the alternative is a rewrite.

For a Laravel stack the fit is negative. Illuminate\Queue with the Redis driver is a superset, maintained in lockstep with the framework, and its job-resolution model (handlers resolved through the container) is the feature this fork adds. The correct integration decision for a Laravel shop is to not integrate.

Migration path

Choose by whether Resque is already load-bearing:

• Resque already in production: adopt glit/resque as a pinned, vendored fork strictly to obtain the job factory. Mirror it into a private Composer repository with a commit-hash constraint; do not consume it from Packagist. Treat it as a bridge with a tracked exit ticket and an owner.
• Greenfield / no Resque investment: skip it. Laravel → QUEUE_CONNECTION=redis with Horizon. Non-Laravel PHP → Symfony Messenger (Redis or AMQP transport) or php-enqueue. All three give maintained code, retries with backoff, failure transports, and a documented operational story.

The exit target should be Symfony Messenger (if staying on Symfony) or Laravel queues (if Laravel), because both preserve the container-resolved job handler property the fork exists to provide — the fork's one advantage evaporates on migration, which is exactly why the migration is cheap.

Compatibility

Verify before writing a line of job code: PHP constraint; ext-pcntl/ext-posix; Redis client and minimum server version; AUTH/TLS/DB-index support; and whether the JSON envelope matches Ruby Resque's ({"class": ..., "args": [...]}). Envelope compatibility matters if anything else in the estate — a Ruby resque-web dashboard, a shared worker pool — reads the same keys. Implement the job factory against the fork's exact interface; if undocumented, write an adapter and pin the fork so a silent upstream change can't break instantiation.

Sequencing (with gates)

1. Spike (2–3 days). One worker, one job class, staging Redis. Gate: forking, signal handling, and container resolution confirmed; confirmed whether the "Laravel service provider" claim is real.
2. Vendor and pin. Private repo, commit-hash constraint, plus a CI job that boots a worker and drains a queue so PHP-version bumps fail loudly. Gate: CI green on the target runtime.
3. Define our own thin job contract and factory wrapper so job classes never import the package's types. This seam is what makes the eventual migration mechanical rather than a rewrite.
4. Build the missing primitives in our layer: idempotency keys, retry-with-backoff, dead-letter/requeue command, max_jobs-style recycling, queue-depth metrics.
5. Migrate handler-by-handler to the target queue; run both fleets on disjoint queue names until drained, then decommission.

Recommendation to stakeholders: do not adopt for any Laravel roadmap item — it would be a strict downgrade plus a maintenance liability. For a legacy Resque estate, approve it only as a time-boxed, vendored bridge with a named owner, a migration ticket, and a sunset date. The durable takeaway is the pattern: jobs are container-resolved, idempotent, unit-testable services — which we get natively from the framework.

Operational Impact

Maintenance

Effectively zero upstream maintenance. Any bug, security advisory, or PHP-version incompatibility is our work. Budget a fork owner and an annual cost to keep it on a supported runtime; if that owner doesn't exist, the package is a latent outage. Zero dependents also means no ecosystem pressure to fix things and no community patches to cherry-pick — every fix is bespoke.

Support

No commercial support, no CVE feed, no release cadence, README-level documentation. Debugging falls to whoever can read the worker source. Runbooks must be written from scratch: how to inspect queue depth, find stuck jobs, requeue safely, and kill a wedged worker without orphaning children. On-call implications: a worker fleet your team cannot page a vendor about is an on-call surface you are choosing to own.

Scaling

Horizontal worker scaling is the package's genuine strength — add processes, add hosts, they contend on the same Redis lists. But the model inherits Resque's ceilings: Redis is a single-threaded single point of failure for the whole queue tier; memory is bounded by queue depth and payload size, so a consumer outage turns into an OOM event; there are no autoscaling signals without us instrumenting queue depth ourselves; and the observability story assumes Ruby resque-web, an extra runtime to host. Concurrency is bounded by process count, and every forked worker carries the full framework bootstrap cost.

Failure modes

Rank these by business impact at assessment time:

• Silent job loss — popped, then killed before in-progress is recorded. Payments, emails, and syncs vanish with no alert. Mitigation: write the in-progress record ourselves, or accept a reconciliation job.
• Stranded jobs — crash mid-execution leaves entries in the in-progress registry forever; a periodic pruner + requeue command is mandatory.
• Poison jobs — no retry cap means a failing job re-executes indefinitely, or (worse) a non-idempotent job double-applies on requeue. Idempotency is a product commitment, not an implementation detail.
• Redis durability — RDB/AOF config bounds what survives a crash; state that guarantee to the business in plain language before a queue carries revenue-affecting work.
• Zombie/orphaned forked children after a redeploy, plus workers silently on an old code version.
• Supply-chain compromise via an unmaintained Packagist name — mitigated by vendoring and hash pinning.

Ramp-up

Developer ramp-up is low: perform() and a factory is a half-day to first job. Operational ramp-up is where the cost sits — forking semantics, signal handling, supervisor units, Redis capacity, and crash recovery. Estimate 1–2 weeks for an engineer to be genuinely confident, plus a named owner for the fork. Do not let a team adopt this without that owner named in the decision record.

Decision ask: approve pattern adoption (container-resolved, idempotent jobs) with no new dependency; reject package adoption for any Laravel work; if a legacy php-resque service exists, open a retirement ticket with a framework-native target and a dated exit milestone before this package appears in any production path.