michel/pqueue-bundle
A priority queue bundle for Laravel/PHP that lets you push jobs with weighted priorities and process the most important work first. Includes queue driver integration, configurable priority levels, and simple APIs for scheduling and managing background tasks.
Architecture fit. This release is a Symfony bundle wrapping michel/pqueue, not a Laravel package. That is the single most important finding for stack-fit purposes: if the target application is Laravel, this release provides no service provider, no config/pqueue.php, no Artisan command, and no Laravel container bindings. It assumes Symfony's bundle/config/DI conventions (config/packages/pqueue.yaml, autoconfigured services, console commands). Fit against a Laravel codebase is therefore effectively zero out of the box, and would require an adapter layer we would own and maintain.
Integration feasibility. Within a Symfony application the surface area is small and conventional: YAML transport configuration, handler discovery via configured sources/classes, injectable Dispatcher and Consumer services, and a pqueue:worker:run console command with memory/time-limit options. This is a comprehensible, low-ceremony contract that a mid-level engineer can wire up in under a day. The feasibility problem is not complexity, it is maturity and the absence of a documented public API.
Technical risk. High, driven by three factors. First, 0.0.1-alpha signals no API stability guarantees — semver at 0.x permits breaking changes in any patch, and the config schema, service IDs, and command name/options are all plausible churn points. Second, the default transport is Filesystem, which is a development convenience rather than a production queue; it implies local-disk coupling that will not survive horizontal scaling or containerized/ephemeral filesystems. Third, the bundle is a thin integration layer over a third-party library, so our exposure is the union of two projects' maintenance risk, and the alpha stage suggests neither has been battle-tested at volume.
Key questions.
michel/pqueue support beyond Filesystem, and are any of them durable and multi-consumer safe?michel/pqueue funded or single-maintainer? What is the issue/response track record?pqueue:worker:run — graceful drain or hard kill mid-job?Stack fit. Conditional. Proceed only if the target is Symfony 5.4+/6.x/7.x with the standard bundle and DI conventions, and only for non-critical workloads initially. If the target is Laravel, treat this release as not applicable and do not attempt to force it through a bridge; the effort saved by adopting the library is smaller than the effort of owning a Laravel shim.
Migration path. There is nothing to migrate from, so this is a greenfield adoption, which is the favorable case. Adopt behind our own thin application-level interface (a QueueDispatcher port plus a worker entrypoint) rather than letting Dispatcher/Consumer types leak into domain code. That keeps the alpha dependency at one seam and makes a later swap to Symfony Messenger — the natural incumbent in a Symfony stack — a contained change rather than a refactor.
Compatibility. Verify PHP version constraints and Symfony component ranges against our pinned versions before anything else; an alpha bundle frequently lags current Symfony minors. Confirm compatibility with our dependency injection compilation (autoconfiguration of handlers depends on correct tags/interfaces), our config cache warmup, and our deployment model — particularly whether the Filesystem transport's storage path is a writable, persistent volume in every environment.
Sequencing.
Maintenance. We inherit a pre-1.0 dependency with an undocumented API, so expect to absorb breaking changes on upgrade. Budget for pinning the exact version, reading diffs before bumps, and maintaining the adapter seam as the stable surface. Cost is modest while the seam is small; it grows quickly if the queue becomes load-bearing.
Support. No commercial support is implied. Escalation is to upstream maintainers via their issue tracker, with no SLA. Internally, one engineer should be named owner of the integration, and the adapter seam plus a documented runbook should exist before production traffic. If the library stalls, our fallback is a rewrite of the adapter against Symfony Messenger — cheap if the seam held, expensive if it did not.
Scaling. The Filesystem transport is a hard ceiling: it presumes a shared, writable, POSIX-compatible filesystem, which breaks on multi-node container deployments, is sensitive to inode and lock contention, and offers no consumer coordination guarantees we can reason about. We should assume single-node operation until a durable transport is proven. Worker concurrency is similarly uncharacterized — no documented guidance on running multiple pqueue:worker:run processes safely.
Failure modes. The release notes are silent on the failure surface, which is itself a risk finding. Unanswered: what happens to an in-flight job when a worker hits its memory or time limit mid-execution; whether jobs are retried and with what backoff; whether poison messages are quarantined or loop forever; what observability exists beyond console output; and whether a crash between dequeue and completion loses the job. Plan to answer these empirically in the spike, and assume no structured metrics or tracing integration until proven otherwise — we will likely need to instrument the worker ourselves.
Ramp-up. Low for a Symfony-fluent engineer — the concepts are standard and the surface is a YAML file plus a console command, roughly half a day to first working job. The cost is not learning the API but de-risking the unknowns above; allocate spike time for failure-mode testing rather than API familiarization. For a Laravel-only team, ramp-up is effectively undefined because the package does not target their stack.
How can I help you explore Laravel packages today?