Retry Subscriber Laravel Package

Product Decisions This Supports

• Reliability posture for outbound HTTP. The decision of how aggressively we retry calls to third parties (payments, shipping, CRM, webhooks, internal microservices) is a product decision about user-visible failure rates, not just an engineering detail. This package makes retry policy explicit and configurable — how many attempts, which status codes, which exceptions, with what backoff — which is exactly the kind of policy that should be owned and reviewed rather than buried in a controller.
• Build vs. buy on resilience plumbing. Custom retry loops written by hand are the usual alternative, and they tend to grow inconsistent (different timeouts, different backoff, occasional duplicate writes on non-idempotent POSTs). A small subscriber middleware standardizes the behavior and reduces the surface area of a "we built it ourselves and it drifted" problem.
• Feature scoping: "retries" vs. "resilience." Retry alone fixes transient blips. It does not fix a dependency that is down for five minutes. Deciding whether the roadmap item is retry or retry + circuit breaking + fallback + idempotency keys changes the buy decision substantially — this package only covers the first slice.
• Use cases where this pays off immediately: third-party APIs with documented rate limits and 429/503 responses; webhook delivery to customer endpoints; batch/scheduled jobs that call external services; synchronous checkout flows where a single retried 502 avoids a lost order and a support ticket.
• Use cases where it is the wrong lever: non-idempotent writes without idempotency keys (retrying a charge twice is worse than failing once), latency-sensitive user-facing requests where backoff would push us past our SLA, and anything where the real fix is caching or moving the call async.
• Roadmap signal: given the package is archived with zero dependents, adopting it is a maintenance liability decision, not a speed decision. This should trigger a "do we take on an unmaintained dependency?" conversation with a clear answer, not a silent composer require.

When to Consider This Package

Consider it only under narrow conditions:

• You are on a legacy Guzzle 4/5 codebase where the built-in RetryMiddleware is unavailable and a rewrite of the HTTP layer is genuinely out of scope for the current quarter.
• You need a drop-in event subscriber on an existing Guzzle client without restructuring how clients are constructed (a genuinely low-diff change on a mature codebase).
• You want retry policy expressed as declarative configuration (max attempts, status codes, exceptions, backoff strategy) attached to specific clients rather than hand-rolled for loops scattered across services.

Look elsewhere — and you almost certainly should — in these cases:

• Guzzle 6+ is in use. guzzlehttp/guzzle ships RetryMiddleware natively. Adding an archived package to duplicate built-in functionality is a net negative for security review, dependency audits, and onboarding.
• You are on Laravel's HTTP client. Http::retry($times, $sleepMilliseconds, $when, $throw) already covers this, is first-party, first-class tested, and integrates with fakes in test suites. This is the default recommendation for Laravel work.
• You need backoff with jitter, circuit breaking, bulkheads, or per-dependency budgets. That is a resilience library decision (Resilience4j-style patterns, or a thin in-house wrapper over Http::retry), not a retry subscriber.
• Compliance or security review gates on unmaintained dependencies. Archived + MIT + zero dependents means no upstream CVE response. If your org has a supported-dependency policy, this fails it on day one.
• The retried operation is non-idempotent and lacks idempotency keys. No retry library fixes that; it just makes the duplicate-charge bug intermittent instead of obvious.

How to Pitch It (Stakeholders)

For executives — one paragraph: Our services make a lot of outbound HTTP calls, and a meaningful share of failures are transient — a 503, a timeout, a rate limit — that succeed on a second attempt. Standardizing on a retry policy converts some of those into successes, which shows up as fewer failed checkouts, fewer dropped webhooks, and fewer support tickets, at effectively zero infrastructure cost. The important caveat: the specific open-source package that prompted this evaluation is archived and unmaintained, so my recommendation is to adopt the pattern — retries with bounded attempts and exponential backoff, applied per-dependency — using the first-party retry middleware already inside Guzzle and Laravel's Http::retry. We get the reliability win with no new unmaintained dependency, no procurement cycle, and no added security-review burden.

For engineering — the ask: Centralize outbound retry configuration into the HTTP client factory (or a small shared trait) rather than per-call-site loops. Use Http::retry() on Laravel 7+ / RetryMiddleware on Guzzle 6+. Define, for each third-party dependency, three things: max attempts, which status codes and exceptions are retryable, and the backoff curve — and write them down. Never enable retries on non-idempotent POSTs until idempotency keys are in place. This package (guzzlehttp/retry-subscriber) is only worth the dependency if we find ourselves on Guzzle 4/5; if that scenario appears, revisit, but treat it as a legacy-only, time-boxed adoption.