Queue Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy vs. adopt — it settles the question as "neither." This bundle is a reference point for how a framework-level command queue was once scoped, not a candidate for adoption. The 0.115 score, 3 stars, zero dependents, and a last release of 2016-05-03 make it an archived artifact rather than a dependency decision. The v1.0.1 release (bug fix for #1, a Logentries logging integration, and getJobByCommand() for querying the status of a time-critical job) is noted and does not change the verdict: small feature additions on an otherwise dormant, low-adoption bundle are a signal of a maintainer patching a personal install, not of a project re-entering active maintenance. It is not a re-entry event, it is not a breaking change, and it is not sufficient to restart an evaluation.
• Framework-fit gatekeeping. The most valuable output is a fast disqualifier: this is a Symfony bundle, not a Laravel package. Symfony bundles are registered through Symfony's kernel/DI container (services, Bundle classes, config.yml), so it does not drop into a Laravel app without an adapter layer and a rewrite of its wiring. v1.0.1 does not touch this — no Laravel service provider, no config/queue.php driver, no facade. Any roadmap item that assumed "PHP package = interchangeable" gets corrected here at near-zero cost.
• Dependency health policy inputs. It is a clean worked example for a maintenance-scoring rubric: time since last release, star count, dependent count, release cadence. Useful when justifying an internal rule like "no new dependency without a release in the last 18 months and at least one downstream consumer," and for sizing the maintenance burden we would absorb if we ever took ownership of a fork (MIT makes that legally trivial, operationally expensive). v1.0.1 is a useful calibration case for that rubric: a version bump with real change that still should not flip a "maintained" flag, because one release after a multi-year gap is not cadence.
• Scope validation for async work. Confirms that the "queue for asynchronous processing of framework commands" problem has consolidated into first-party solutions — Symfony Messenger on the Symfony side, Laravel's queue + Horizon on ours — with Redis, RabbitMQ, or database backends. Any product spec proposing a homegrown or third-party async command dispatcher should be benchmarked against those, not against a 2016 bundle.
• What the new release partly addresses. getJobByCommand() is a status-lookup entry point, and the Logentries integration is a logging sink — both are narrow, job-level conveniences rather than a monitoring or observability surface. Worth stating precisely so the assessment isn't wrong in a review: there is now some answer to "where did my job go," but it is a synchronous status lookup and a log shipper, not dashboards, alerting, throughput/latency metrics, or failure trend analysis.
• What it still does not unlock. No retry/backoff guarantees, no dead-letter handling, no monitoring or observability platform, no PHP 8 or modern Symfony compatibility to rely on. It should not appear as a line item in a capacity plan, a reliability OKR, or a compliance review.

When to Consider This Package

Adoption criteria — and why it still fails nearly all of them:

• Maintained within the last 12–18 months: technically now passes on a date basis because of v1.0.1, but fails on substance — one release does not establish cadence, and the maintainer's own backlog shows a single issue triaged. Treat "last release date" as necessary, not sufficient, in the rubric.
• Signals of real production use: fails (3 stars, 0 dependents, no downstream consumers to learn from, so no one to ask about the new status-lookup path).
• Compatible with our runtime and framework: fails on both axes — it targets Symfony, and there is no evidence v1.0.1 adds modern PHP or Symfony major-version support.
• Documented behavior for failure modes: fails/unknown — the new features ship without docs in the release notes, and there is no community to validate them.
• A migration path off it exists: trivially yes (MIT, small surface), which is the only box it checks.

Consider it only as a reading reference — a few hours of source review to see how a minimal command-queue abstraction was structured, now including how a minimal job-status lookup and an external log sink were layered on. That is a genuinely useful pattern to read if we ever build a small internal dispatcher. Even then, copy patterns, not code.

Look elsewhere — decisively — when the requirement is production async processing, retries, priorities, scheduled jobs, or observability. Route to Symfony Messenger if the target app is Symfony, or Laravel's native queue with Horizon (Redis/RabbitMQ/SQS/database drivers) if it is Laravel. Those are first-party, maintained, and documented.

How to Pitch It (Stakeholders)

For executives (two sentences): We re-reviewed kuborgh/queue-bundle after a v1.0.1 release and still recommend against adoption — it is a Symfony bundle with no downstream consumers, and a single small release after a multi-year gap (a bug fix, a Logentries logging hook, and a job-status lookup) does not constitute a maintained dependency for our Laravel stack. The equivalent capability, including status tracking and monitoring, is already first-party in both frameworks (Laravel Horizon / Symfony Messenger), so there is no buy decision and no budget ask here.

For engineering: Do not add this dependency. The v1.0.1 changes are minor and additive — getJobByCommand() gives a point-in-time status lookup for a submitted job, and the Logentries integration ships logs to an external sink. Neither is a substitute for Horizon's dashboards, retry/backoff semantics, or dead-letter handling, and neither addresses the underlying problem that this is a 2016-era Symfony bundle with three stars, zero dependents, and no upstream to inherit security patches from. The MIT license makes forking legally simple but leaves us owning the code forever, which is a worse trade than the ~few days of work to wire up Laravel's native queue and Horizon. If we need a dispatcher on the Symfony side of the estate, use Symfony Messenger.

Bottom line for the roadmap: this stays a no-go with a known-good alternative, re-confirmed in under an hour. Log the v1.0.1 review in the dependency register — update the reason to "framework mismatch; single release after multi-year dormancy, no downstream consumers" — and spend no further cycles on it.