Octane Coroutine Laravel Package

Technical Evaluation

Package identification. The release notes describe a Laravel runtime-integration layer for long-lived PHP workers (Swoole/Octane config surface: octane.swoole.redis_pool, base-application rebinding/terminating callbacks, request-scoped bus dispatcher). All evaluation below is scoped to that role: a package that substitutes for, or wraps, laravel/octane.

Architecture fit. Strong. The two fixes address the single most consequential architectural hazard of running Laravel under a long-lived worker: request state escaping its request. Forwarding refresh()/rebinding()/terminating() to the base application caused (a) unbounded callback accumulation on the worker, (b) the session guard reading the boot request instead of the current one — silently breaking remember-me and basic auth — and (c) terminate() re-running every prior request's callbacks on every subsequent request. That is a monotonic, age-correlated performance decay plus a correctness bug in auth. Any team running this package in production is exposed today; the fix is not a nicety, it is the difference between "works in staging, rots in prod" and a stable runtime.

The afterResponse() fix is the same class of defect with a clearer blast radius: a single dispatch + 40 requests produced 41 executions. For anyone using after-response jobs for email, webhooks, or billing side effects, this is duplicate-execution territory. Treat as a correctness fix with data-integrity implications, not a perf fix.

Integration feasibility. High, with one hard caveat. The behavioral changes require no consumer code changes — the old behavior was unambiguously wrong, and it is difficult to construct a legitimate dependency on it. The Redis connection pool is opt-in and default-off, so it can be adopted on a separate, later decision boundary from the correctness fixes.

The caveat is packaging, not code: v0.8.37 is byte-identical to v0.8.36, and exists only because Packagist indexed v0.8.36 while its tag briefly pointed at the v0.8.35 commit — and still serves that mapping. That means composer update resolving to 0.8.36 gets you the pre-fix code. Any version constraint that permits 0.8.36 (^0.8, ~0.8.36, *) is unsafe and will silently under-deliver.

Technical risk.

• Medium — terminate()/callback scoping changes worker-level behavior. Low probability of legitimate breakage; high impact if something in your app registered a callback expecting base-app persistence (e.g. a service provider that intentionally registers once per worker from a request path — an anti-pattern, but it exists in the wild).
• Medium — after-response jobs now run once. If any downstream consumer was written to tolerate or deduplicate the duplicate executions, that logic becomes dead weight; if any consumer depended on re-execution, it was already broken.
• Medium — the Redis pool introduces a new failure surface: a lease held past its request throws rather than sharing the socket. That is the right trade (fail loud vs. corrupt), but it converts a previously-silent path into an exception under load. Sockets are only returned when "provably clean," which shifts risk to pool exhaustion under bursty concurrency (max_idle 16, max_idle_time 60s, ping_after_idle 5s, max_lifetime 300s are all defaults to review against your traffic shape).
• Low-to-medium — verification matrix is PHP 8.3/8.4 and Laravel 11/12/13. If you are on PHP 8.2 or Laravel 10, you are outside the verified envelope. Production evidence is one image (modelslab-frontend-v2, Swoole + nginx), which is a good signal but a single data point.

Key questions for the maintainer / vendor.

1. What is the version constraint we should standardize on to guarantee the 0.8.35→0.8.37 code and never the mis-indexed 0.8.36 mapping? Is there a plan to re-tag or supersede 0.8.36 on Packagist?
2. Is octane.swoole.redis_pool intended as generally available or experimental? What is the promotion criterion?
3. Under Redis failover/restart, does the pool discard stale sockets and reconnect, or can a worker latch onto a permanently dead connection? Is there a documented drain/recycle procedure for deploys?
4. How does the pool interact with per-request SELECT / multi-tenant database switching and AUTH rotation? The notes imply cleanliness is validated — what specifically is checked?
5. Is there a stated support matrix (PHP/Laravel versions) and a security disclosure policy? What is the maintenance/bus-factor posture?
6. Is 0.8.x considered pre-1.0 / unstable, and are minor versions allowed to carry behavior changes of this magnitude?

Integration Approach

Stack fit. Fits any Laravel 11–13 service on PHP 8.3/8.4 currently running Swoole, RoadRunner, or FrankenPHP workers — and, importantly, fits the default php-fpm/artisan serve case at zero cost, since the fixed code paths are inert outside a long-lived worker. No new infrastructure is required for the correctness fixes. The Redis pool requires only that you already use Redis (session/cache/queue), which is the common case.

Migration path. Two independent steps, deliberately decoupled:

1. Correctness upgrade (do this first, mandatory). Pin the exact version — "<vendor>/<package>": "0.8.37" — not a range. Run composer update <package>, then verify with composer show and a diff against the tag that the deployed code is the 0.8.37 tree, explicitly confirming you are not on the stale 0.8.36 mapping. composer.lock must be committed. This step should be doable in a single sprint with a staging soak.
2. Redis pool adoption (optional, separate change). Enable octane.swoole.redis_pool.enabled in staging only, after step 1 has soaked. Tune max_idle and max_idle_time against measured concurrency. Treat as an independent go/no-go.

Compatibility. Confirm PHP and Laravel versions against 8.3/8.4 and 11/12/13 before committing. Teams on older minors should not assume safety from "no breaking changes listed" — the notes describe untested combinations, not tested-and-fine ones.

Sequencing.

1. Pin and upgrade in a branch; run the full test suite plus an auth regression pass (remember-me, basic auth, session persistence across requests) — these are the paths the bug corrupted, so existing tests likely do not cover them.
2. Add a targeted regression test asserting terminating() callbacks fire once and only for their own request.
3. Add a test asserting a single dispatch(...)->afterResponse() runs exactly once across N sequential requests in the same worker.
4. Deploy to staging under a long-lived worker; soak at least a few hours with realistic traffic and record worker RSS, per-worker request count, and callback/queue side-effect counts.
5. Production rollout of step 1 as a normal deploy; rollback is a version pin revert.
6. Then evaluate the Redis pool: enable in staging, load test to observe connection counts and any lease-overrun exceptions, and only then canary on one worker group in production.

Operational Impact

Maintenance. Low ongoing cost, but version pinning discipline is now mandatory rather than nice-to-have. The 0.8.36 Packagist mapping means a loose constraint can silently roll you onto pre-fix code during an unrelated composer update — a genuinely nasty failure mode because it looks like an innocuous dependency refresh. Add a CI check that asserts the installed version and, ideally, the resolved commit.

Support. This release materially reduces support load: the terminate()-replay bug meant a worker slowed down as it aged and ran an ever-growing pile of stale callbacks, which produces exactly the kind of unreproducible, "it's fine after a restart" incident that consumes disproportionate on-call time. Fixing the session-guard-reads-boot-request bug also removes a class of intermittent auth failures that are typically misattributed to the identity provider or the browser.

Scaling. The headline number is the strongest part of this release: Redis connections per request 2.0 → 0.004, with flat throughput when worker recycling is disabled. That has three concrete operational consequences:

• Ephemeral port exhaustion (Cannot assign requested address) under load disappears as a failure mode — previously a hard ceiling on request rate per node, now removed.
• Worker recycling can be turned off (or relaxed), which eliminates the deploy-style cold-start latency hit and lets you run hotter, denser nodes.
• Container state stops growing — flat RSS over worker lifetime is the property that makes long-lived-worker runtimes predictable enough to autoscale on.

Failure modes to instrument.

• Lease overrun exceptions — new, by design; alert on them rather than treating them as noise. Rising counts indicate pool sizing or max_idle_time is wrong, or that a code path is holding a connection across an await/queue boundary.
• Pool exhaustion under burst — with max_idle at 16, a concurrency spike may exceed idle supply and fall back to opening connections; confirm fallback behavior is degrade-not-fail.
• Stale sockets after Redis failover — verify reconnect, or you trade port exhaustion for a wedged worker fleet.
• Silent under-delivery of the fix — a worker still on 0.8.35/0.8.36 code looks healthy and degrades slowly. Assert the version at boot.
• Changed after-response job counts — if you have downstream dedup logic, it is now dead code; if you have alerting on job volume, expect counts to drop and confirm that is the fix, not an outage.

Ramp-up. Engineering ramp-up is near zero: the correctness fixes are transparent, and the pool is one config flag. The real ramp-up is on-call and platform: whoever owns the workers needs to learn to read per-worker age, RSS, Redis connection counts, and lease-exception rates as a coherent story, and needs a documented procedure for draining a pool during deploy/Redis maintenance. Budget a short runbook update and a dashboard panel for the pool — small, but non-zero, and worth doing before enabling the flag rather than after the first incident.