Product Decisions This Supports
- Async processing architecture — whether to offload slow work (emails, exports, webhook fan-out, image processing) to background workers, and which substrate to bet on: self-hosted Redis queue vs. database queue vs. managed cloud queue.
- Build vs. buy vs. wrap — this package is a thin Symfony2 service-container integration around
php-resque; the real build/buy decision is about the queue engine, not the bundle. Useful for framing "integration glue" as a cost center rather than a product asset.
- Legacy estate roadmap — informs contain-vs-replatform calls for Symfony 2.x applications. If this bundle is already in the dependency tree, it's a signal the app is frozen.
- Dependency governance — zero stars, zero dependents, no visible maintenance is a concrete input to an allowlist/denylist policy and to supply-chain risk scoring in vendor review.
- Operational cost forecasting — self-hosted Resque implies a worker fleet, supervisor config, Redis HA, retry/DLQ policy, and monitoring. That ops budget should be compared against a managed queue before committing.
- Platform alignment — flags a mismatch worth resolving early: this is a Symfony2 bundle, not a Laravel package. It will not slot into a Laravel container, so any Laravel roadmap item that assumes it is based on a false premise.
When to Consider This Package
Consider it only when all of the following hold:
- The application is on Symfony 2.x (through 2.8) and is in maintenance mode with no replatform budget this cycle.
- You are already running php-resque or Ruby Resque and want container wiring rather than hand-rolled bootstrap code.
- You are willing to vendor and fork it, treat it as owned code, and assign an engineer as maintainer.
- Security/compliance review accepts an unmaintained, zero-adoption dependency.
Look elsewhere when any of these are true:
- New build of any kind. No maintainer, no adoption, EOL host framework — the risk is not worth the saved wiring.
- Laravel. Wrong framework entirely; use Laravel's queue system with Horizon, or a managed queue driver.
- Symfony 3.4+ / 4+ / 5+ / 6+. Use Symfony Messenger (first-party, maintained) or a supported Enqueue transport.
- You need retries, dead-letter queues, scheduling, a dashboard, or per-job metrics. Resque-family tooling is thin here; Horizon/Sidekiq-class observability is a real gap.
- You want managed infrastructure (SQS, Cloud Tasks, managed Redis) and the lowest possible ops headcount.
- Dependency policy requires a maintained upstream — this will not clear review.
How to Pitch It (Stakeholders)
To executives: This is a legacy integration shim, not a strategic capability. It has no adoption signal, no apparent maintainer, and it is pinned to a Symfony version that reached end of life years ago. Recommendation: do not adopt it for anything new; if it is already in production, treat it as contained technical debt and fund a small, time-boxed exit plan rather than an upgrade.
To engineering: Understand what it actually is — dependency-injection wiring for php-resque, a small amount of glue. That means it is cheap to replace and cheap to fork, but also that nobody upstream is watching it. If we must keep it: vendor it, pin the version, add it to the owned-code list, and name an owner.
The alternative, costed: Symfony Messenger is first-party and maintained and covers the same job; Laravel's queue plus Horizon covers it if we move that direction; a managed cloud queue minimizes ops to near zero. Present these as a single decision record with a recommendation, rather than as an open-ended debate — the decision is really "which queue substrate do we standardize on," and this bundle should be recorded as rejected with the reasoning above.