Swoole Bundle Laravel Package

Product Decisions This Supports

• Runtime strategy for high-traffic Laravel services. This package underpins an async, long-running worker runtime (Swoole HTTP server, DB/Postgres/Redis connection pools, cache adapter). v1.3.0 is the release that makes that strategy defensible in a security review — previously, adopting it meant accepting a known header-injection path and an unserialize object-injection risk in the cache layer.
• Go/no-go on replacing PHP-FPM for latency- or throughput-sensitive endpoints. The atomic-sized connection pools (replacing non-thread-safe int $currentSize) remove a class of production incidents — pool overruns and lost connections under multi-worker load — that would otherwise surface as 3am pages during traffic spikes. That de-risks the scaling decision.
• Build vs. buy (build vs. adopt). Correct CRLF sanitization and safe cache (de)serialization are cross-cutting hardening problems that are easy to get subtly wrong and expensive to maintain in-house. This release is a signal to adopt rather than fork or hand-roll a Swoole integration.
• Platform upgrade roadmap alignment. Explicit compatibility with PHP 8.2–8.4, Symfony 7.0/8.0 and Swoole 6.0+ means this dependency does not block an upcoming PHP/Symfony upgrade — a common reason such packages get deferred or ripped out.
• Roadmap sequencing for caching. The allowed_classes => false change is a behavioral tightening disguised as "no migration required." Any product surface relying on object caching (serialized DTOs, Eloquent models, session payloads in the Swoole cache adapter) needs a migration to arrays/plain structures — plan this as a small, scheduled work item, not a silent version bump.
• Vendor-risk and release-cadence decisions. That multiple critical security defects shipped in prior versions informs how much of the core request path you want to entrust to this package, and whether you need a pin-and-patch policy, a fork, or commercial support.

When to Consider This Package

Adopt when:

• You are running or evaluating a Swoole-based runtime for Laravel/Symfony and your traffic profile justifies escaping PHP-FPM's per-request bootstrap.
• You operate multiple workers with pooled DB, PostgreSQL or Redis connections — the thread-safety fix is precisely for you, and is the strongest reason to upgrade.
• You are on PHP 8.2+, Symfony 7/8, Swoole 6.0+ — you are inside the supported matrix.
• You need a hardened HTTP layer (validated headers/URIs) because you build response headers from user input, proxies, or tenant identifiers.
• You have staging capacity for a load test and the engineering depth to debug long-running worker state (memory growth, static leakage, container reuse).

Look elsewhere when:

• No Swoole extension, PHP < 8.2, Swoole < 6.0, or shared hosting — you are outside the compatibility envelope entirely.
• You already run Laravel Octane with RoadRunner or FrankenPHP. Overlapping runtimes fragment operational knowledge; consolidate rather than run two.
• Your app is low-traffic or latency-insensitive — the operational overhead (worker restarts, memory tuning, pool sizing) is not repaid.
• You cache serialized PHP objects in the Swoole cache adapter. Post-1.3.0, allowed_classes => false will silently degrade or break object hydration. If you cannot migrate that payload to arrays/DTOs on a near-term timeline, this release is a functional regression for you, not a free win.
• You require commercial SLAs, English-first documentation, or a large maintainer bench — validate bus factor before making it load-bearing.
• You need a drop-in HTTP server with no code-level constraints (no shared state, no request-scoped singletons) — Swoole's programming model is a real architectural commitment, not a config flag.

On this specific release: treat it as mandatory for anyone already on the package — the security fixes are critical and there is no migration step. Treat it as conditionally blocking only for object-caching workloads, where a verification spike (roughly half a day) should precede the bump. Note the release notes are in French and do not document the cache behavior change as a breaking change; the "no action required" claim should be validated against your own code rather than taken at face value.

How to Pitch It (Stakeholders)

For executives (one paragraph): A security and stability patch for the async PHP runtime underlying our high-throughput services. It closes two critical vulnerabilities — malicious header injection via the HTTP layer and remote code execution via unserialized cache objects — and fixes race conditions that could drop database and Redis connections under load. It is free, backward compatible, requires no migration work, and keeps us on the supported path for our upcoming PHP 8.4 and Symfony upgrades. Recommendation: apply immediately, with a brief staged load test before full rollout.

For engineering leadership:

• Risk removed: CRLF header injection (HttpServerManager), object injection via allowed_classes => true (SwooleCacheAdapter), and non-atomic pool counters across three pool implementations.
• Cost to adopt: a version bump, one staging load test at target worker concurrency, and a code grep for object caching through the Swoole cache adapter — the only place the fix can bite.
• Watch items: header sanitization may now reject values previously accepted (custom headers, encoded redirects); verify nothing depended on the looser behavior. Pin the version, and add connection-pool saturation and worker memory to dashboards for the first week.
• Process ask: the existence of these defects in earlier releases argues for a standing policy — dependabot/security advisory monitoring plus a quarterly review on this dependency, rather than ad-hoc upgrades.