Laravel Queue Consumer Laravel Package

Product Decisions This Supports

• Reliability investment in async workloads. The 1.2.0 fix addresses a silent data-loss class of bug: jobs released by WithoutOverlapping, RateLimited, ThrottlesExceptions, or an explicit $this->release(60) were executed, released, exited 0, and then dropped by the hub with no exception, no failed-job record, and no log line. For any product surface backed by queues (billing, notifications, webhooks, imports), this is the difference between "we retry" and "we lose the work and never know." Use it to justify prioritising consumer-side reliability work over new queue features.
• Build vs. buy for cross-runtime queue bridging. This package is the consumer side of a hub-and-spoke queue topology — a PHP/Laravel worker pulling payloads from an external hub. The 1.2.0 release shows the maintainer is closing semantic gaps between Laravel's native queue contract and the hub transport, which is exactly the kind of work a team would otherwise own and maintain internally. Adopting it is buying a narrow, well-understood piece of plumbing rather than a platform.
• Backpressure and rate-limit correctness. Retry/backoff semantics (release($delay)) are where throttling middleware actually earns its keep. Before 1.2.0, RateLimited and ThrottlesExceptions were effectively decorative on this transport — a released job vanished instead of backing off. If your roadmap depends on respecting third-party API quotas, this release makes that promise real.
• Multi-queue routing decisions. The new --queue= flag lets a released job return to its originating queue instead of always landing on default. That unlocks per-queue worker topologies (e.g. critical, bulk, webhooks with different concurrency and failure budgets) without released jobs collapsing into a single lane and starving priority work.
• Failure-visibility SLAs. The stated behaviour change — "a hub that refuses the re-post makes the command fail loudly instead of losing the job" — converts a silent-loss failure mode into an observable one. That directly supports SLOs and on-call runbooks: you can now alert on consumer exit codes and re-post failures rather than discovering lost jobs from customer reports.
• Rollout risk management. Because the re-posted payload goes back untouched, the hub needs no changes, and --queue defaults to default so hubs that don't send a queue keep working. This is a low-coordination-cost upgrade — useful when arguing for shipping it in the next sprint rather than batching it into a larger migration.

When to Consider This Package

Consider adoption when:

• You run Laravel queues across a hub-and-spoke architecture where a non-Laravel or central service dispatches payloads to PHP workers, and the native queue:work daemon can't speak to that hub directly.
• You rely on WithoutOverlapping, RateLimited, ThrottlesExceptions, or manual release($delay) in jobs executed on this transport. Before 1.2.0 those were unsafe; 1.2.0 is the minimum viable version for these patterns. Treat 1.2.0 as the floor for any new adoption.
• You need per-queue isolation for retried work — the --queue= flag is the deciding feature if released jobs must not all funnel into default.
• You want failure to be loud rather than best-effort — the new fail-on-refused-re-post behaviour matters for teams with on-call rotations or audit requirements around job delivery.
• You're evaluating narrow, single-purpose packages over adopting a full queue platform; this one is small, opinionated, and its changelog shows disciplined scope.

Look elsewhere when:

• You're on a single Laravel app with a standard driver (Redis, SQS, database). Laravel's native queue worker already handles release/backoff correctly; this package adds a hop without adding value.
• You need a general-purpose job orchestration layer — chaining, batching, fan-out, cross-service sagas, or a UI for queue observability. This package is a consumer, not a control plane.
• You require strong at-least-once guarantees with idempotency built in. 1.2.0 fixes the "release drops the job" hole, but re-posting a payload still implies the hub must tolerate duplicates; idempotency remains your responsibility (or the hub's).
• You can't accept a default-queue regression during rollout. If your hub doesn't yet send a queue name, released jobs will arrive on default — if your topology has no worker listening there, you've converted one failure mode into another. Verify hub-side queue propagation before enabling per-queue workers.
• The project's bus factor or maintenance cadence doesn't fit your risk profile — a single-maintainer package sitting in your critical job path warrants a fork-or-vendor contingency plan.

How to Pitch It (Stakeholders)

For executives: We depend on a queue consumer to move asynchronous work between our systems. Version 1.2.0 fixes a silent job-loss bug: when a job asked to be retried later — because of a rate limit, a lock conflict, or an explicit backoff — the consumer reported success while the hub discarded the job. No error, no failed-job record, no log. Work simply disappeared. This release makes retries actually retry, and makes a hub rejection fail loudly instead of quietly. It's a correctness fix on infrastructure we already run, requires no hub-side changes, and the new queue flag defaults to today's behaviour — so it's a low-risk upgrade we should schedule now.

For engineering: Upgrade to 1.2.0 as the minimum version wherever released jobs occur. Mechanics: SyncJob::release() only flipped a flag, and sync has nowhere to push to, so release($delay) was a no-op that still exited 0. Jobs now run through a HubJob that captures the delay the base release() discards and re-posts the untouched payload back to the hub with that delay; a refused re-post fails the command rather than losing the job. queue-consumer:run --queue= controls which queue released jobs return to (defaults to default, so existing hubs are unaffected). Action items: (1) verify hub payloads carry a queue name before rolling out non-default queues, (2) add alerting on consumer non-zero exit and re-post failures, (3) confirm jobs on this transport are idempotent, since re-post implies possible duplicates, (4) add a regression test covering a released job surviving to a second attempt.