Laravel Actions Laravel Package

Product Decisions This Supports

• Build vs. buy for background operation execution. The package already owns the plumbing for dispatching operations as queued jobs (serialization, dispatch, overlap handling). Each release that adds config knobs rather than requiring custom code is evidence the buy side keeps getting cheaper — factor the release cadence into any build-vs-buy comparison against an in-house job wrapper.
• Idempotency and duplicate-work policy. 7.3.0 adds a configurable uniqueness lock duration, which turns "how long do we consider two runs of this operation to be the same run?" from a code change into a config value. This is directly relevant to anything with side effects: double-charging, duplicate notification emails, repeated webhook fan-out, competing report generation.
• Queue topology and isolation strategy. The queue.job config override lets you substitute your own job class without forking the package. That unlocks product-level decisions like routing certain operations to a dedicated queue/connection, injecting tenant context, applying a standard retry/backoff policy, or layering in tracing — all without owning the dispatch layer.
• Correctness expectations for scheduled/overlapping work. The --isolated fix aligns the package with Laravel core presence semantics. If "only one of these runs at a time" is a promise you make internally (billing reconciliation, nightly syncs), a semantics-alignment fix reduces the class of bugs where behavior differs between environments or between core Artisan and this package.
• Roadmap sequencing. Because 7.3.0 is additive configuration, it is a low-risk release to absorb now, which argues for queuing adjacent feature work (e.g. per-operation lock tuning, custom job classes for tenancy) rather than deferring it behind an infrastructure project.

When to Consider This Package

Adopt when:

• You already run operations or artisan-style work as queued jobs, and duplicate or overlapping execution is a real product risk rather than a theoretical one.
• You need per-operation control (how long a run is considered unique, which job class is dispatched) without maintaining a fork or a parallel dispatch layer.
• You want framework-consistent semantics for isolation/overlap behavior instead of bespoke guards that drift from Laravel core over time.
• Your team is comfortable with queue semantics and can reason about lock duration, retries, and backoff — the new config surface is powerful but easy to misconfigure.

Look elsewhere when:

• A single-server scheduler with no concurrency is sufficient — the abstraction is overhead you won't recover.
• You need durable, multi-step workflow orchestration (compensation, long-running sagas, human-in-the-loop steps); this is a job-dispatch layer, not a workflow engine.
• You require guarantees the package doesn't state (strict at-most-once delivery, cross-datastore locking, formal audit trails) — those belong in your own layer or a different product.
• Lock duration behavior depends on your cache/lock backend; if you can't operate that backend reliably, configurability becomes a new failure mode rather than a feature.

How to Pitch It (Stakeholders)

For executives: this release makes duplicate-execution protection and job customization configuration instead of engineering work. Practically, that means fewer incidents where the same operation runs twice and produces a real-world side effect — a duplicate charge, a duplicate email, a repeated sync — and less bespoke code we have to maintain to prevent it. It is an additive release with no breaking changes called out, so the cost of taking it is a routine upgrade plus a short verification pass.

For engineering: 7.3.0 adds two config levers and fixes one behavioral mismatch. (1) Uniqueness lock duration for queued operation jobs is now configurable — review current defaults against your longest expected runtime and your retry window before adopting. (2) queue.job lets you swap in a custom job class — the natural hook for tenancy, queue routing, and observability, and a way to stop maintaining patches. (3) --isolated now matches Laravel core presence semantics — treat this as a behavioral change, not a pure bugfix: audit any operation that relied on the previous interpretation, and verify in staging before rollout. Recommended path: pin 7.3.0 in staging, exercise the highest-side-effect operations, confirm lock durations explicitly rather than inheriting defaults, then promote.