Laravel Haystack Laravel Package

Product Decisions This Supports

• Feature delivery of multi-step async workflows. Laravel Haystack lets you chain queued jobs and persist the chain (haystack) in the database, so long-running sequences — onboarding drips, order fulfilment pipelines, document/import processing, per-tenant batch jobs — survive worker restarts, deploys, and queue failures. This replaces hand-rolled "state table + cron sweeper" orchestration for a large class of features.
• Build vs. buy vs. OSS. It sits between Laravel's native Bus::chain() (in-memory, lost on restart) and heavyweight orchestrators (Temporal, AWS Step Functions, Laravel Workflow). For teams on Laravel 10/11 with existing queue infrastructure, adopting this package is usually 1–3 days of work versus weeks to build equivalent durability and retry semantics.
• Roadmap sequencing. If the roadmap includes delayed sequences measured in hours/days, job-to-job data passing, or appendable then/catch/finally callbacks, this package makes those one-sprint items rather than a platform initiative.
• Operational recovery decisions (reinforced by v2.2.0). Previously a failing job could remove the haystack record; v2.2.0 keeps the haystack on failure. That makes "retry, resume, or abandon" an explicit support/product decision backed by retained data, and it turns failed workflows into an inspectable queue rather than a silent loss.
• Instrumentation and support tooling. Because haystacks and haystack jobs are rows, you can build internal dashboards ("where is customer X's workflow?"), SLA alerting, and manual re-drive tooling — product-visible capabilities that are hard to offer with in-memory chains.

When to Consider This Package

Adopt when:

• Chains must survive deploys, worker restarts, or queue:restart; native Bus::chain() losing progress is a real, observed failure mode.
• You need per-job delays spanning minutes to days, with the schedule persisted rather than held in memory.
• Jobs need to return data consumed by the next job in the chain.
• You want global then / catch / finally hooks appended at dispatch time for completion notifications, cleanup, or audit logging.
• You already run Redis/SQS/database queues and are comfortable operating two additional tables.
• You need to name, resume, or cancel a running chain programmatically (e.g., user-initiated cancellation in a UI).

Look elsewhere when:

• You only need short, fire-and-forget chains where a retry from the top is acceptable — native chaining is simpler and has zero storage cost.
• You need visual DAG authoring, human-in-the-loop approvals, complex parallel fan-in/fan-out with joins, or cross-language workers — Temporal, Cadence, or Laravel Workflow fit better.
• Throughput is extreme and per-step database writes become the bottleneck; the durability is bought with I/O.
• You cannot own retention: haystack tables grow, and v2.2.0's retained-on-failure behaviour makes pruning/archival a required operational task, not an optional one.
• You require a commercially supported, multi-maintainer dependency; this is a single-maintainer OSS package (mitigate with a small surface area, tests, and a fork plan).

How to Pitch It (Stakeholders)

For executives: This is a small, free, open-source package that removes a meaningful chunk of custom engineering from any feature involving multi-step background work. It makes long-running workflows durable across deploys and crashes, which directly reduces "half-finished process" incidents that generate support tickets and manual clean-up. No vendor lock-in and no new infrastructure — it stores state in the database you already run. Cost is measured in engineering days, not licences.

For engineering: Opt-in via a trait on jobs you already write; it wraps the existing queue connection and adds haystacks / haystack_jobs tables. You get persistent chains, per-job delays, data passing between jobs, and dispatch-time then/catch/finally hooks. v2.2.0 is a reliability fix: a failed job no longer deletes its haystack, so failed chains remain inspectable and recoverable — check any cleanup jobs or dashboards that assumed the record disappeared on failure, and confirm retention/pruning is in place before scaling usage. Risks are the usual OSS ones: single maintainer, schema you now own, and table growth. Mitigations are cheap — pin the version, add a scheduled prune, and keep the integration behind a thin internal abstraction so it can be swapped.