Octane Coroutine Laravel Package

Product Decisions This Supports

• Octane / long-running worker migration. This release removes the class of bugs that make Swoole or RoadRunner deployments look "fine at deploy, broken by lunchtime." That directly de-risks a roadmap item most Laravel teams have parked: moving off PHP-FPM for throughput and cost.
• Build vs. buy on request isolation. Request-scoped refresh()/rebinding()/terminating() forwarding and after-response job dispatch are exactly the plumbing teams end up hand-rolling (and getting subtly wrong) during an Octane migration. Adopting this package replaces a custom, hard-to-test workaround with a maintained one.
• Infrastructure sizing and cost decisions. The opt-in Redis connection pool changes per-request Redis connections from 2.0 to 0.004, which moves Redis connection limits, AUTH/SELECT overhead, and ephemeral-port exhaustion off the capacity-planning critical path. That is a direct line item in both hosting cost and incident load.
• Prioritising a specific reliability fix. Existing production symptoms — worker memory creeping up over a deploy's lifetime, duplicate afterResponse() jobs firing on unrelated later requests, remember-me/basic auth intermittently failing, Cannot assign requested address under load — now have a concrete, low-risk remedy. If any of these are in the backlog, this release is the fix rather than a workaround.
• Use cases: high-throughput APIs, apps with heavy Blade rendering under Octane (one callback registered per request), multi-tenant or stateful-auth applications where cross-request bleed is a correctness — not performance — issue, and any Redis-dependent service running behind a long-lived worker.

When to Consider This Package

Adopt when:

• You run, or have approved a plan to run, Octane with Swoole/RoadRunner, or you maintain a long-lived worker runtime of your own.
• You are seeing any of the failure signatures above: worker state that grows with uptime, terminate() callbacks executing repeatedly, after-response jobs or batches re-running, session-guard auth reading an empty request, or Redis connection errors at scale.
• You want the Redis pool improvement but not at the cost of correctness — the design only returns provably clean sockets and throws on an over-held lease, which is the right failure mode for a pooled socket.
• You can pin an exact version. Pin v0.8.37 specifically. v0.8.36 is still served by Packagist with a mapping to the v0.8.35 commit, so requesting "0.8.36" or a caret range may resolve to code without these fixes. Verify the lockfile resolves to v0.8.37.

Look elsewhere or wait when:

• You deploy on standard PHP-FPM or a per-request process model — none of these fixes apply, and you inherit an unnecessary dependency.
• You have no Redis in the stack; the headline performance feature is inert.
• You need a stable API contract. At v0.8.x this is pre-1.0 software with config keys that can move; treat upgrades as scheduled work, not routine patch bumps.
• Your Redis usage depends on connections being shared across coroutines in a way that conflicts with per-request leases — validate the max_idle, max_idle_time, ping_after_idle, and max_lifetime defaults against your traffic profile before enabling.
• A framework-native or first-party solution already covers request rebinding for your runtime.

Rollout note for whoever owns deployment: the Redis pool ships default-off. Enable it behind a flag in staging, confirm connection counts and latency under real traffic, then roll forward. The callback fixes need no flag — they are corrections, and shipping them is the priority.

How to Pitch It (Stakeholders)

For executives: This release closes a set of production reliability defects that only surface after a service has been running for a while — degrading throughput, duplicated background jobs, and intermittent authentication failures on long-lived workers. Fixing them removes a recurring class of incidents that our dashboards are slow to attribute, because the symptoms are indistinguishable from ordinary load. It also adds an optional performance improvement that cuts Redis connections per request from 2 to 0.004, which reduces infrastructure pressure and removes a known cause of connection-refused outages under peak traffic. Cost is an upgrade and a staging validation window. Risk is low: the performance feature is opt-in and off by default, and the correctness fixes were verified across PHP 8.3/8.4 and Laravel 11/12/13, plus a production image under Swoole with nginx, showing no growing container state and flat throughput.

For engineering: Two things to internalise. First, the bug being fixed is architectural, not cosmetic: callbacks were being forwarded to the base application instead of the current request, so every request permanently added a callback to the worker, the session guard read the boot request rather than the live one, and terminate() executed every prior request's callbacks at the end of each subsequent request. Under Octane the Blade engine registers one such callback per request, so cost grew monotonically with worker age. The bus dispatcher had the same shape — request-scoped, but registering on the base app — which is why one afterResponse() dispatch produced 41 executions across 41 requests and now produces 1. Second, the Redis pool is a deliberate opt-in with conservative semantics: only provably clean phpredis sockets are reused, and a lease held past its request raises rather than silently sharing a socket. Tune max_idle, max_idle_time, ping_after_idle, and max_lifetime against observed traffic before enabling in production. Pin v0.8.37 in the lockfile — v0.8.36's tag-to-commit mapping on Packagist is stale, so a resolved 0.8.36 gets you the pre-fix code.

One-line summary for a status update: Mandatory upgrade for anyone on Octane — it stops worker state accumulating and background jobs duplicating — with an optional, safe-by-default Redis pooling win that takes per-request connections from 2.0 to 0.004. Pin v0.8.37.