Resque Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy vs. adopt-existing for background processing. This package is a thin glue layer between Symfony 2's DI/config and php-resque; the real components are Redis and php-resque. If we already operate Redis, adoption cost is roughly one Composer dependency plus config. If we don't, the actual decision is "add Redis to the platform," and this bundle is incidental.
• Roadmap sequencing for a legacy service. If a product already runs on Symfony 2, this dependency effectively pins the service to Symfony 2. Every feature request touching async work becomes coupled to a re-platform line item — that's a roadmap fact worth surfacing early.
• MVP scope: what can be deferred. A queue primitive is what lets us ship email sends, PDF/report generation, webhook fan-out, image processing, and third-party API sync after the HTTP response. This package answers "how cheaply can we add async work?" with "cheaply — but only inside a Symfony 2 app."
• Framework-fit / routing decision. The request framed this as a Laravel/PHP package; it is a Symfony2 bundle with a 2021 last release. For a Laravel codebase the correct answer is the native queue API plus Horizon; for Symfony 4+, Symfony Messenger. That mismatch is itself the most valuable output of this assessment.
• Exit and containment planning. 4 stars, 0 dependents, and a single stale release mean there is no community to inherit maintenance. That supports a decision to wrap the queue behind an internal interface so a future swap is localized rather than a rewrite.
• Hiring and supportability. Adopting this adds a skill requirement (Symfony 2 + php-resque) that essentially no new hire will have. A PM can use that to argue for re-platforming ahead of new feature work rather than after.
• Risk-register entries. No security disclosure path, no active maintainer, PHP/Symfony version floor, and no built-in observability are all items a PM should be able to name before an architecture review.

When to Consider This Package

Adopt (narrowly) when:

• The application is genuinely on Symfony 2.x and a framework upgrade is not funded this cycle.
• Redis is already in production and operated by someone on the team.
• The alternative is worse: a hand-rolled Redis list with a cron-driven worker loop and no retry/failure semantics.
• Job semantics are simple — fire-and-forget, at-least-once, idempotent payloads. php-resque gives retries and a failed-job list, but no first-class scheduling, deduplication, or delayed jobs without extra work.
• The team explicitly accepts ownership of the code, including forking or vendoring it.

Look elsewhere when:

• Any Laravel codebase. Use Laravel's native queue with Horizon. This bundle does not belong there.
• Symfony 4/5/6/7. Use Symfony Messenger with the Redis or Doctrine transport — first-party, maintained, better DX, same conceptual model.
• Observability matters — per-job metrics, dead-letter inspection, retry dashboards, alerting on queue depth. Resque's web UI is Ruby-era tooling; you will build this yourself.
• Security or compliance review applies. An abandoned glue package with no security policy is a supply-chain question, not a convenience question.
• Traffic is high or spiky enough that queue operations become a service — at that point you want a managed queue (SQS, Cloud Tasks) or a maintained broker, not a 4-star bundle.
• The team has no Redis operational experience. The queue is easy; Redis persistence, eviction, and failure modes are not.

How to Pitch It (Stakeholders)

For executives: This package lets a legacy Symfony 2 application do background work — sending email, generating reports, syncing to third parties — without blocking the user's request, for roughly a day of integration effort. But it is a stopgap, not a platform: the dependency is effectively unmaintained (4 GitHub stars, zero known dependents, last release November 2021) and the framework beneath it is end-of-life. Recommendation: use it only to buy time inside an app already on Symfony 2, behind an internal interface so the eventual switch to Symfony Messenger is contained. Do not introduce it into new services, and do not use it in Laravel.

For engineering: This is a small bridge from Symfony 2's container and configuration to php-resque, a Redis-backed job runner. The code is small enough that vendoring or wrapping it is safer than depending on it directly — that removes the version-floor and abandonment risk while keeping the behavior. The durable work is not the package: define job payload contracts, idempotency keys, retry and failure handling, and a dead-letter review process. Those decisions outlive any library here. Treat the queue as infrastructure with a named owner, because an abandoned dependency becomes an incident the moment Redis or PHP is upgraded, not before.