- What is stancl/jobpipeline used for in Laravel?
- JobPipeline lets you turn an ordered series of Laravel job classes into an invokable event listener. It is a thin composition layer over Laravel's event dispatcher and queue bus, not a full workflow engine. Its main architectural benefit is mapping an event object once into a job payload with a send closure, so the jobs themselves stay event-agnostic and reusable.
- How do I install stancl/jobpipeline?
- Install it with Composer using composer require stancl/jobpipeline. There is no service provider, config file, or migration to publish. You define your job classes and register the pipeline wherever your application accepts an event listener.
- How do I register a JobPipeline as an event listener?
- Build the pipeline with JobPipeline::make, configure send, and call toListener to get an invokable listener object. The toListener output can be registered anywhere Laravel accepts a listener, including Event::listen or an EventServiceProvider setup that supports object listeners. There is no package service provider to register.
- How do I pass event data to the jobs in a JobPipeline?
- Call send with a closure that receives the event and returns the payload your jobs should receive. The event is transformed once at listener invocation, then the same payload is passed through the job series. This keeps jobs decoupled from specific event classes and makes them reusable.
- How do I queue a JobPipeline, choose a queue, or make pipelines queued by default?
- Pipelines are synchronous by default; call shouldBeQueued(true) to queue one. Pass a queue name as the second argument to shouldBeQueued, such as shouldBeQueued(true, 'another-queue'), to push it to a specific queue. To queue all pipelines by default, set the static property JobPipeline::$shouldBeQueuedByDefault to true.
- Which Laravel and PHP versions does stancl/jobpipeline support?
- The package targets Laravel 10 through 13 and PHP 8.1 through 8.4 according to release notes. Both 1.x and 2.x tracks have received compatibility releases, but 2.x has been in release-candidate status across multiple RCs. Check the specific release notes before standardizing on a version in production.
- What happens when a job in a queued JobPipeline fails or the pipeline retries?
- A queued pipeline behaves like one queue job containing the step list, so a failure at a later step can cause a retry from the first step. Any non-idempotent step, such as database creation, payment capture, or email sending, can duplicate on retry unless the job detects prior completion. The package relies on a manual idempotency contract; returning false from a job is a silent, success-shaped cancel that should be logged explicitly.
- How do I monitor a multi-step JobPipeline in Horizon or Telescope?
- Horizon, Telescope, and Sentry typically see one job per pipeline rather than one record per step. That means mean-time-to-diagnosis for a failed multi-step workflow depends on each job emitting its own structured logs. Add per-step logging with pipeline and correlation identifiers if you need to distinguish completed, skipped, and failed steps.
- Can I use closures as pipeline steps in a queued JobPipeline?
- Closures inside pipelines were added in 1.5.0, and closure error handling has been patched in later releases. A closure captured as a step cannot cross a queue boundary unless it is wrapped by Laravel's SerializableClosure. Verify serialization behavior in the exact package version before using closures in queued pipelines.
- How does JobPipeline compare to a workflow engine, and when should I choose an alternative?
- JobPipeline is best treated as syntactic sugar over Laravel's queue chain plus declarative event-to-payload mapping. It does not provide branching, fan-out or fan-in, human tasks, a state machine, or compensating transactions. Choose a dedicated workflow engine when you need those features or stronger per-step observability and failure semantics.