Doctrine Delay Queue Driver Bundle Laravel Package

Technical Evaluation

Architecture fit. This is a Symfony bundle, not a Laravel package. It ships a Symfony Bundle class, a DI extension and compiler passes, and depends on mcfedr/queue-manager-bundle plus Doctrine ORM. There is no Illuminate\Support\ServiceProvider, no queue Connector/Queue contract implementation, and no config/queue.php registration hook. Architectural fit with a Laravel application is effectively zero without an adapter layer that would be larger and more fragile than the package itself.

Functional overlap. Laravel already ships a database queue driver that persists jobs to a jobs table with available_at for delayed dispatch, plus backoff, max exceptions, failed_jobs dead-lettering, and queue:work supervision. The capability this bundle exists to provide — delayed background work with a relational database as the only infrastructure dependency — is native to the framework. There is no capability gap for a Laravel stack to fill.

Integration feasibility. Low, in both directions. The last release is 2018-04-17, targeting PHP 5.6/7.x and Symfony 2/3-era APIs. Modern Symfony (6/7) has symfony/messenger with a doctrine:// transport, which is the direct and maintained successor to this pattern. Any adoption requires forking and modernizing first.

Technical risk. High. Abandoned for 7+ years, 2 stars, 0 dependents, no security response path, and transitive constraints pinned to old Doctrine DBAL/ORM majors. Supply-chain exposure is real: any fork immediately becomes code we own in perpetuity.

Key questions.

• What requirement is this being evaluated against? If the answer is "delayed jobs without adding Redis or RabbitMQ," Laravel's database driver already answers it at zero dependency cost.
• Does the estate actually contain a legacy Symfony service where this is already deployed? If so, this is a removal/maintenance question, not an adoption question.
• Is there a live queue-manager-bundle dependency somewhere, or is this being lifted from a stale candidate list?
• Who owns the fork if we adopt, and what is the fully-loaded 3-year cost of that ownership?

Integration Approach

Stack fit. Mismatch — recommend no direct integration. Route the underlying requirement to Laravel's built-in queue system:

• QUEUE_CONNECTION=database with the standard jobs / job_batches / failed_jobs migrations.
• Delayed dispatch via dispatch(...)->delay($when) maps directly onto available_at — the same mechanic the Doctrine driver implements.
• Run queue:work under Supervisor or systemd. Horizon is optional and only relevant if Redis is already acceptable; it is not required for this pattern.

If the hard constraint is "no new infrastructure beyond the existing RDBMS," the native driver satisfies it with zero third-party code.

If a Symfony component genuinely exists, do not use this bundle. Migrate to symfony/messenger's Doctrine transport, which is core-maintained and covers the same delayed-message semantics. Treat this bundle as an artifact to remove, not add.

If a specific semantic must be ported (because the bundle does something Laravel's driver does not), port the schema and poller into a first-party Laravel queue connector rather than adapting the bundle:

1. Migration for a delayed_jobs table: id, queue, payload, available_at, reserved_at, attempts, created_at.
2. Implementation of Illuminate\Contracts\Queue\Queue (push, later, pop, release, delete).
3. Connector registered in a service provider and exposed in config/queue.php.

Estimated 3–5 engineer-days including tests — strictly cheaper than owning a fork.

Compatibility. No path to PHP 8.2+/Laravel 10/11 without a fork. Symfony 6/7 removed several conventions the 2018 bundle relies on (bundle inheritance patterns, older DI aliasing).

Sequencing.

1. Spike (1 day): confirm the requirement and document in writing why the native database driver does or does not suffice.
2. If native suffices: config + migrations only; ship in the current sprint. No new dependency.
3. If a port is justified: schema → connector → worker → load test → cut over.
4. If a legacy Symfony service is in scope: schedule its migration to Messenger's Doctrine transport on a separate track; do not couple it to Laravel delivery.

Operational Impact

Maintenance. The dominant concern. No releases since 2018, no active maintainer, zero dependents. Every PHP/Doctrine/Symfony upgrade becomes an unbudgeted fork task. Native Laravel queue components ship with the framework and are upgraded alongside it.

Support. None available. No vendor, no community of scale, no CVE feed. A 02:00 incident has no upstream to escalate to — only our own fork maintainers. Contrast with the native driver, which the framework team and a large user base actively support.

Scaling. Poller-based Doctrine queues scale poorly against purpose-built brokers. Every worker polls the table on an interval, so idle capacity still generates query load. Workers race for rows, requiring SELECT ... FOR UPDATE SKIP LOCKED or an equivalent reservation strategy to avoid double processing under concurrency. Throughput is bounded by the RDBMS write path and index contention on available_at; this becomes the bottleneck well before a Redis- or SQS-backed queue would. Laravel's database driver has the same shape, so this is not a differentiator — but it argues against any DB-backed queue if volume growth is expected.

Failure modes.

• Poison jobs: the 2018 design lacks a clear dead-letter equivalent to failed_jobs; a persistently failing job may loop.
• Orphaned reservations: a worker crash mid-job leaves rows reserved with no timeout-based reaper, silently stalling that queue segment.
• Clock skew: delayed_until correctness depends on worker and database clock agreement, particularly across nodes.
• Schema drift: Doctrine entity schemas deployed out of band with bundle updates is a known fragility of this family of packages.
• Silent stall: no built-in metrics or health surface; a stopped poller looks identical to an idle system until the backlog is inspected.
• Laravel's native driver mitigates most of these via failed_jobs, retry_after, queue:retry, queue:monitor, and Horizon metrics.

Ramp-up. The codebase is small, so reading it costs a few hours. The real cost is domain mismatch: a Laravel team would need Symfony bundle/DI/Doctrine fluency to debug it, and that knowledge does not transfer to the rest of the platform. Native queue internals are also non-trivial, but they are documented, ubiquitous, and already familiar.

Recommendation. Do not adopt. The score (0.13) and low opportunity signal (1.73) are consistent with an abandoned, framework-mismatched, zero-dependent package. Close the evaluation, resolve the underlying requirement with Laravel's database queue driver, and — if a Symfony service is genuinely in scope — target symfony/messenger's Doctrine transport instead.