- Does mcfedr/doctrine-delay-queue-driver-bundle work with Laravel?
- No. The package is a Symfony bundle: it ships a Bundle class, a DI extension and compiler passes, and depends on mcfedr/queue-manager-bundle plus Doctrine ORM. There is no Illuminate service provider, no queue Connector or Queue contract implementation, and no hook into config/queue.php, so Laravel never discovers it. Making it work would require an adapter layer larger and more fragile than the package itself.
- Can I install this package with Composer in a Laravel project?
- Composer may resolve the constraint, but nothing will register or run. Laravel only auto-discovers Illuminate service providers, and this bundle exposes Symfony bundle metadata instead. You would end up with an unused dependency and old Doctrine DBAL and ORM constraints pinned into your dependency graph. The correct action is to remove it rather than require it.
- Which PHP and Laravel versions does this bundle support?
- The last release was 2018-04-17 and targets PHP 5.6 and 7.x with Symfony 2 and 3 era APIs. There is no path to PHP 8.2+ or Laravel 10 and 11 without forking and modernizing, because Symfony 6 and 7 removed bundle inheritance and DI aliasing conventions the code relies on. Laravel 10 and 11 require PHP 8.1 or newer, so the version ranges do not intersect.
- Is this package maintained and safe to use in production?
- No. It has been abandoned for over seven years with roughly two stars, zero dependents, and no security response path. Transitive constraints are pinned to old Doctrine DBAL and ORM majors, which creates real supply-chain exposure. If you fork it, you own that code and its CVE response in perpetuity.
- What is the Laravel equivalent of the Doctrine delay queue driver?
- Laravel's built-in database queue driver covers the same ground: jobs persist to a relational table and delayed dispatch is stored in an available_at column. On top of that you get backoff, maxExceptions, failed_jobs dead-lettering, job batching, and queue:work supervision. The core capability this bundle exists to provide is native to the framework at zero third-party dependency cost.
- How do I run delayed background jobs in Laravel without Redis or RabbitMQ?
- Set QUEUE_CONNECTION=database, publish the standard jobs and failed_jobs migrations with the queue:table and queue:failed-table commands, and run migrations. Delayed dispatch is then just dispatch(...)->delay($when), which writes into available_at exactly as the Doctrine driver does. Supervise queue:work with systemd or Supervisor; Horizon is optional and only relevant when Redis is already acceptable.
- What are the alternatives to this bundle for delayed database-backed jobs?
- On Laravel, the native database queue driver is the direct answer and needs no new infrastructure. On Symfony 6 and 7, symfony/messenger's doctrine transport is the maintained successor with the same delayed-message semantics, and it is core-maintained rather than abandoned. Reach for Redis, SQS, or RabbitMQ only when throughput or cross-service fan-out actually demands it.
- How do I migrate from this Doctrine delay queue to Laravel's queue system?
- Create the standard queue tables, switch the connection to database, and translate stored payloads into queued job classes that Laravel can unserialize. If a specific semantic must survive, port the schema (id, queue, payload, available_at, reserved_at, attempts, created_at) into a first-party connector implementing Illuminate\Contracts\Queue\Queue, register it in a service provider, and expose it in config/queue.php. That port is roughly three to five engineer-days including tests, which is strictly cheaper than owning a fork of the original.
- How do I test delayed jobs on Laravel's database queue driver?
- Use Queue::fake() with assertPushed and assertPushedWithDelay to verify dispatch intent without touching the database. For the storage layer itself, run against SQLite in memory with RefreshDatabase and assert rows appear in the jobs table with the expected available_at. Keep at least one integration test that runs queue:work once against a real connection so the reserved_at and release paths are exercised.
- When would adopting or forking this bundle ever make sense?
- Only if your estate already runs a legacy Symfony service where it is deployed, and then it is a removal and maintenance question rather than an adoption one. For a Laravel application the answer is no: confirm the underlying requirement in a one-day spike, document why the native database driver does or does not suffice, and ship configuration and migrations instead of a dependency. If you do fork, assign a named owner and budget the fully loaded three-year ownership cost before committing.