- What is laravel-queue-consumer and when should I use it?
- It is a Laravel package that consumes jobs from an external queue broker (the hub) and runs them inside your application instead of relying on a local queue worker. It is aimed at ephemeral review environments and similar short-lived deployments where running a supervisor and worker per environment is wasteful or impractical. It is not a replacement for Horizon or a full queue backend; it bridges a non-Laravel broker into Laravel's worker lifecycle.
- How do I install and run the queue consumer in a Laravel app?
- Install it with composer require jeffersongoncalves/laravel-queue-consumer, then run the queue-consumer:run command under a process supervisor so it stays alive. The --queue option defaults to default, so hubs that do not send a queue name keep working without extra configuration. No hub-side deployment is required to get started.
- How does the package integrate with Laravel's queue system internally?
- The package synthesises a job object (SyncJob, now wrapped by HubJob) that satisfies Laravel's job contract but has no real queue driver behind it. It runs the payload in-process and reports completion back to the hub over HTTP. Because there is no driver, the package owns delivery semantics such as retries, releases and backoff that Laravel normally handles for you.
- Which Laravel and PHP versions does version 1.2.0 support?
- The package targets Laravel's queue job contract, and 1.2.0 introduces the HubJob wrapper that sits on top of the existing SyncJob. The exact Laravel and PHP matrix for 1.2.0 should be confirmed in the package's composer.json before upgrading, since the wrapper is the piece most likely to have narrowed compatibility versus 1.1.0. Check your app's framework constraint against that requirement before bumping.
- What changed in version 1.2.0 for released jobs?
- Before 1.2.0, release() only flipped a flag because the synthetic sync job had nowhere to push, so released jobs were acknowledged as delivered and then dropped. Version 1.2.0 captures the discarded delay, re-posts the untouched payload to the hub, and lets the hub remain the source of truth for re-delivery. Keeping the payload unchanged means the hub needs no changes to work with the new behaviour.
- Do RateLimited, WithoutOverlapping and ThrottlesExceptions now work with this consumer?
- Yes, in the sense that release() now actually re-posts to the hub instead of being a silent no-op, which is what those middlewares depend on. Previously every middleware that relied on releasing, including $this->release($delay), had no effect on a consumed job. They only behave as real backoff if your hub supports delayed re-delivery; otherwise they degrade into a tight retry loop.
- Does my hub need to support delayed re-delivery for release delays to work?
- Yes. release($delay) is only meaningful if the hub accepts a delayed re-post, so confirm its minimum and maximum delay granularity per deployment before enabling these middlewares. If the hub only accepts immediate re-posts, RateLimited, ThrottlesExceptions and WithoutOverlapping turn into rapid retry loops against the hub rather than a backoff. This is a hub capability question, not a Laravel capability question.
- Which queue do re-posted jobs land on after a release?
- Released jobs from a worker that was not started with --queue= return on default rather than the queue they originally came from. In multi-queue deployments this silently moves load and can starve the original queue. The default is backward-compatible but not behaviour-preserving, so start workers with an explicit --queue where queue routing matters.
- Are attempts, maxTries and retryUntil preserved across the hub round trip?
- That is not stated in the release notes, so treat retry accounting as unspecified until you verify it with your hub implementation. If the attempts counter resets on every re-post, a job that keeps releasing itself, such as one using ThrottlesExceptions, can loop indefinitely. Ask whether the re-posted payload carries an incremented attempts counter and whether the hub enforces a maximum-attempt cutoff.
- Can consumed jobs be delivered twice, and do they need to be idempotent?
- Yes. A re-post that succeeds at the hub but whose acknowledgement is lost will be redelivered, and nothing in this release provides deduplication. Jobs dispatched through the consumer should therefore be written to be safely re-runnable. This matters more in 1.2.0 than before, because released jobs now genuinely come back instead of being dropped.