Retry Laravel Package

Product Decisions This Supports

• Turning "resilience" into a written retry policy. This package exists to answer one narrow question: when a dispatched command fails transiently (deadlock, network blip, rate limit), does the system retry, how many times, with what backoff, and what does the user or operator see? That is a product requirement you own regardless of whether this code ever ships. Use the package as a prompt to write the requirement down: attempt count, backoff curve, idempotency expectations, duplicate-work tolerance, and how terminal failures surface.
• Build vs. buy — the answer is "neither, use native." Retry is now a first-class framework capability: queue $tries / $backoff / retryUntil, RateLimited job middleware, Bus::batch()->allowFailures(), Http::retry(), and the retry() helper. Buying an archived 2018 middleware to reimplement this is negative value: a dependency, a supply-chain entry, and a maintenance obligation for something you already have.
• Legacy estate triage, not feature roadmap. If this package appears in a dependency scan, the useful signal is "this team is running a Laravel 5-era service," not "this team needs retries." It should feed a modernize-or-freeze decision with an owner, a date, and a budget line — not a backlog item to "upgrade the retry library."
• Reference design for our own middleware. Read it as a short worked example of a Laravel pipeline middleware. That is genuinely useful input when specifying command-level retries (as opposed to queue-level retries), which native primitives cover less directly.
• Error-budget and SLO conversations. A concrete retry policy forces the uncomfortable questions: what counts as success for a transient failure, how many duplicates are acceptable, and whether retries are masking a systemic fault or absorbing normal noise.

When to Consider This Package

Adoption criteria — deliberately very narrow:

• You are on a Laravel 5.0–5.5-era codebase still using the Illuminate\Bus\Dispatcher command pipeline with SelfHandling-style commands.
• You are prepared to fork and own it (MIT permits this): vendor it, add tests, pin the version, and set a removal date.
• Native queue retry genuinely does not apply — e.g., synchronous commands dispatched through the bus that never touch a queue worker.

Look elsewhere when:

• You're on Laravel 6+. Use native $tries / $backoff / retryUntil, RateLimited, and job middleware. No third-party dependency, no fork.
• You need HTTP-level retries. Use Http::retry().
• You need dead-letter handling, visibility, or dashboards. Horizon, Sentry, or a queue platform gives you this; this package gives you none of it — it retries quietly.
• You need maintenance, security response, or community support. Archived, last release September 2018, 11 stars, 0 dependents. That is a supply-chain and knowledge-risk line item, not a feature.
• You need observability into retries. You would have to instrument it yourself; there is no metrics or logging surface to build on.

How to Pitch It (Stakeholders)

Executives: "There's a small, abandoned library in one of our services that retried failed commands on an old Laravel version. It isn't a capability we should buy or keep — retry is native to the framework now. The real decision is whether the legacy service it lives in gets modernized or frozen. I'm asking for modernization budget, not a new dependency."

Engineering: "Don't adopt alt-three/retry. It targets Laravel 5's command pipeline, hasn't shipped since 2018, has zero dependents, and has no maintenance or security-response path. Treat it as a design reference only. Implement retries with native primitives — $tries / $backoff / retryUntil, RateLimited, Bus::batch()->allowFailures(), Http::retry(). If we're stuck on a 5.x service in the meantime: fork it, pin it, test it, and put a removal date on it. Either way we write the spec — attempt count, backoff, idempotency, and failure surfacing — because that spec outlives the package."