- Is kamisama/php-resque-ex-scheduler compatible with Laravel?
- Not natively. It has no Laravel service provider, config wrapper, or integration with Laravel queues or the Laravel Scheduler. It only makes sense in a Laravel app that already runs php-resque-ex workers and needs a Redis-backed scheduler sidecar. For standard Laravel queue setups, use Laravel Scheduler with Redis or database queues instead.
- How do I install kamisama/php-resque-ex-scheduler?
- Install it with Composer and run its CLI scheduler process alongside your php-resque-ex workers. You also need a compatible Redis client, php-resque-ex, job classes, and queue naming conventions in place. Because there is no Laravel package wrapper, plan on infrastructure-level setup rather than a Composer-only change.
- Does it support PHP 8 and modern Laravel versions?
- The package is archived, last released around 2015, and appears to be PHP 5-era. PHP 8+ and modern Laravel compatibility are not guaranteed and must be proven with a dependency and runtime audit. Expect possible conflicts with modern Composer constraints, Redis clients, and framework dependencies.
- Can I use it with Laravel queues instead of php-resque-ex?
- No, it is built as a scheduler for php-resque-ex, not Laravel's queue system. It stores delayed and recurring schedules in Redis and enqueues jobs to Resque queues. If you are using Laravel's Redis, database, or SQS queues, Laravel Scheduler is the lower-risk fit.
- How does it handle delayed and recurring jobs?
- It keeps scheduling state in Redis and uses a dedicated CLI scheduler process to enqueue jobs for future execution. Delayed jobs run after a specified interval, while recurring jobs use cron-style definitions. The scheduler process must be kept running for those jobs to be enqueued reliably.
- Is php-resque-ex-scheduler still maintained?
- It is archived and has a small community, with the last release dating to 2015. There is no active release stream, vendor SLA, or guaranteed security response. The MIT license allows a fork, but your team would then own patching, PHP upgrades, Redis compatibility, and bug fixes.
- How do I prevent duplicate scheduler processes?
- The package does not provide Laravel-native health checks or first-class observability, and scheduler high availability is unresolved until proven. You need process supervision plus an external locking or leader-election approach to avoid running multiple schedulers that enqueue the same jobs. Test duplicate enqueue behavior before production adoption.
- What happens to missed jobs after downtime?
- Missed-job behavior is a key risk and must be tested for your exact version and configuration. The scheduler is a long-running polling process, so downtime can affect when delayed or recurring jobs are enqueued. Confirm recovery behavior, idempotency of job classes, and whether missed schedules are replayed.
- How should I test it before using it in production?
- Start with a dependency and security audit, then build a proof of concept with representative one-off and recurring jobs. Run the scheduler in parallel with your existing scheduling, shadow the outputs, and compare enqueue behavior. Gate production on missed-job, duplicate-job, restart, timezone, and DST tests.
- What is the best migration path away from php-resque-ex-scheduler?
- Treat it only as a legacy bridge while php-resque-ex is already your job runtime. Inventory existing jobs, queues, schedules, and Redis keys, then migrate queue-by-queue to Laravel Scheduler or a maintained queue system. Keep a documented rollback and decommission plan, and assign an internal owner if you fork the package.