Product Decisions This Supports
- Recurring/periodic job architecture: This package addresses a specific capability decision — how to run work on a schedule (every N minutes/hours) while keeping it inside an existing queue abstraction rather than spawning separate cron entries per job. It is useful mainly as a pattern reference for that decision, not as an adoption candidate.
- Build vs. buy for scheduling: Because it was built as a thin driver for an existing queue abstraction (Queue Manager Bundle), it illustrates the low-effort path of "plugin into an existing bundle" versus writing a bespoke scheduler. In modern stacks the "buy" answer has shifted to native framework schedulers (Symfony Scheduler/Messenger, Laravel's task scheduler), so this is a data point for the "build on what the framework already ships" side.
- Scope of background processing roadmap: Informs whether your roadmap item is "recurring jobs must be first-class and introspectable" versus "periodic jobs are an operational concern handled outside the app." This package assumes the former.
- Platform fit check: Note the naming — this is a Symfony bundle, not a Laravel package. It only makes sense in a Symfony application already using
mcfedr/queue-manager-bundle. If your product is Laravel-based (as the framing suggests), it is not a viable off-the-shelf option and should be recorded as out-of-scope for the platform decision.
- Risk/vendor assessment for dependencies: 1 star, 0 dependents, and no release since September 2017 make it a case study in dependency-lifecycle risk — useful when justifying a policy that new third-party dependencies need recent releases and active maintenance.
When to Consider This Package
Consider it only if all of the following are true:
- You are maintaining a legacy Symfony application that already depends on
mcfedr/queue-manager-bundle.
- You need periodic dispatch of queue jobs and want to avoid adding a parallel cron/scheduler layer.
- You accept responsibility for the code yourself — i.e., you are willing to fork and maintain it, and you've reviewed it for compatibility with your PHP and Symfony versions.
Look elsewhere (strongly recommended) if any of these apply:
- Greenfield or actively developed product. Use Symfony Messenger + the Scheduler component, or Laravel's queue + task scheduler, which cover periodic jobs natively and are maintained.
- Laravel/PHP web app (the stated context). This bundle does not integrate with Laravel's container, service providers, or queue manager; there is no fit.
- You need operational guarantees: retries, overlap prevention (no two instances of the same periodic job running concurrently), missed-run handling, timezone/DST-correct schedules, and observability. The modern framework schedulers and mature tools (cron with locking, Sidekiq/Celery-style schedulers, Kubernetes CronJobs) provide these explicitly; this package does not evidence them.
- Supply-chain or compliance constraints require maintained dependencies with recent releases and a security response path. Last release in 2017 fails that bar — it likely targets PHP 5.6/7.0-era APIs and unmaintained Symfony versions.
- You need multi-node coordination. Periodic dispatch inside a queue driver needs explicit locking to avoid duplicate runs per node; verify this exists before relying on it, and assume it does not.
How to Pitch It (Stakeholders)
Bottom line: recommend not adopting. Use as a reference design only.
For executives: We evaluated mcfedr/periodic-queue-driver-bundle, a small MIT-licensed Symfony bundle that adds periodic/recurring job execution to an existing queue manager bundle. It is effectively unmaintained — one GitHub star, zero dependent packages, and no release since September 2017 — and it is a Symfony component, so it does not fit our Laravel-based platform. Adopting it would create a support and security liability with no offsetting benefit, since the scheduling capability it provides is now standard in both Symfony and Laravel. No cost, no dependency, no roadmap change.
For engineering: This is a thin driver over mcfedr/queue-manager-bundle; it presumes that bundle's abstractions and a Symfony-era service container. On a modern stack, replace it with the framework's native scheduler (Symfony Scheduler + Messenger, or Laravel's task scheduler with withoutOverlapping/onOneServer for multi-node safety). If a legacy Symfony service is already on the queue manager bundle and cannot be migrated, fork the driver, pin it, and add explicit overlap locking and missed-run handling — but budget maintenance ownership, because upstream is dormant. If we do any work here, the deliverable is a short internal note documenting the recurring-job pattern and our chosen native alternative, not a dependency addition.