Rapira Symfony Bundle Laravel Package

Technical Evaluation

What shipped. v0.2.0 is the substantive release; v0.2.1 only relaxes the rapira/contract constraint to stable ^0.9.1, removing the minimum-stability: dev requirement. The pairing matters: the dependency is now installable in a governed, locked-down Composer configuration without weakening stability flags for the whole project.

Architecture fit. The package is fluffydiscord/rapira-symfony-bundle — a Symfony bundle that boots the application through a Symfony Runtime so that public/index.php serves both the dispatcher/worker mode and conventional mode. This is a persistent-process, worker-model runtime in the RoadRunner/FrankenPHP family. That is the single most important architectural fact for our evaluation: it changes the process lifecycle assumptions of the application (long-lived workers, per-worker database connections, per-request state isolation) rather than being a library we call into.

Laravel fit is the open risk. Despite being framed as a Laravel/PHP package, the artifact is Symfony-centric: it depends on Symfony Runtime, and it uses kernel.terminate listener semantics for upload lifetime. Laravel has an analogous terminable lifecycle, but not an identical event contract. A Laravel front controller is not a Symfony Runtime front controller out of the box, so "drop it in and run public/index.php" is a claim that needs verification on a real Laravel skeleton, not assumed. We should treat Laravel support as unproven until we spike it.

Maturity signals. Still 0.x. The 0.2.0 changelog is essentially a list of correctness and isolation defects that only exist in worker mode — PHP sessions and stray output leaking between requests, request-body/upload/cookie parsing divergence from PHP-FPM, zero-byte uploads, header handling hardening. Fixing them is good; the fact that they were all present in 0.1.x is a reminder that this class of bug is inherent to worker-mode PHP and that the test surface is young. The PHP 8.4 dispatcher-runner fix suggests a narrow CI matrix.

Key questions.

• Does a Laravel 10/11/12 app actually boot under this runtime, or only Symfony kernels? Request a reference app or run our own spike.
• What is the maintainer/bus factor and the CI matrix (PHP versions, DB drivers, Laravel vs Symfony suites)?
• How is per-worker state reset proven? Is there a leak-regression test suite we can run against our own service providers and singletons?
• Database reconnection semantics: what happens under a failover, a proxy-side idle timeout, or a rolling Postgres restart — retry, throw, or silent stale handle?
• Does anything in our app rely on register_shutdown_function, fastcgi_finish_request, or $_SERVER keys that worker mode reproduces imperfectly?
• Upload lifetime in kernel.terminate — is there a temp-file cleanup guarantee, or do we own it?
• Support posture: is there a paid/commercial backer, or is this single-maintainer?

Integration Approach

Stack fit. Best fit is a Symfony service or a shared PHP platform team comfortable owning a custom runtime. If the target is a vanilla Laravel product, I would not commit to this as a platform decision yet — I'd sequence it as an experiment behind one non-critical service.

Migration path (0.1.x → 0.2.x). Explicit and mechanical, but breaking in configuration:

1. composer config extra.runtime.class 'FluffyDiscord\RapiraBundle\Runtime\Runtime'
2. composer dump-autoload
3. Edit rapira.toml: [pool] → [http.pool], entrypoint vendor/.../worker.php → public/index.php
4. Remove any deployment scripts, Dockerfiles, or supervisor configs that reference the vendored worker.php — it no longer exists.

Step 4 is the one that bites in production: the vendored entrypoint was likely baked into image builds and process managers. Rollback to 0.1.x also requires restoring that path, so the upgrade is not trivially reversible once images are rebuilt.

Compatibility. Requires rapira/contract ^0.9.1 and Rapira 0.9.1. That pin means we are coupled to a specific Rapira minor line; a Rapira upgrade is a coordinated change. v0.2.1's stable constraint is the prerequisite for our Composer governance (no global minimum-stability: dev), so 0.2.1 is the floor, not 0.2.0.

Sequencing.

1. Composer/governance review — confirm ^0.9.1 resolves under our stability settings and passes license + vulnerability scanning.
2. Laravel feasibility spike on a throwaway app: boot, route, session, file upload, DB query, queue dispatch, one terminable listener. Timebox it.
3. Runtime hardening in a staging service: soak test for state leakage (consecutive requests asserting no session/output bleed), DB failover drill, upload-to-terminate test.
4. Update container images and process manager configs, then cut over one service.
5. Only then consider broader adoption.

Operational Impact

Maintenance. 0.x versioning means minor bumps can carry breaking changes — 0.2.0 is proof. Budget for reading changelogs on every bump and for pinned-version discipline. Composer-level coupling to rapira/contract ^0.9.1 adds a second upgrade axis (the Rapira server itself). Expect nontrivial ongoing cost even with zero code changes.

Support. Single-vendor, pre-1.0, no stated LTS. Escalation path is the upstream issue tracker. For anything revenue-bearing, we need an internal owner who can read the bundle source — it is small enough that this is realistic, but it must be an explicit staffing decision rather than an assumption.

Scaling. Worker mode changes the capacity model: concurrency is bounded by worker count, not by PHP-FPM's process-per-request elasticity. Persistent per-worker DB connections mean pool size is workers × pool_size; sizing must be reconciled against database max_connections and any PgBouncer/ProxySQL limits before launch, or we will discover it during a traffic ramp. Autoscaling on CPU is weaker here — the right signal is worker saturation/queue depth.

Failure modes to design for.

• Connection death: server drops a worker's DB connection and the bundle replaces it. We need to confirm behaviour under rolling DB restarts and failovers, and watch for reconnect storms when a whole pool drops simultaneously.
• State leakage: sessions and stray output leaking between requests was a real 0.1.x defect. Regression testing must be a permanent part of our pipeline, not a one-time check, because any new singleton or static we introduce can reintroduce it.
• Upload lifecycle: files remain readable in kernel.terminate. If our cleanup assumed removal at response send, we now have a retention/disk-growth risk.
• Docroot exposure: with public/index.php as the sole entrypoint for both modes, misconfigured web servers that root at the project directory instead of public/ become a live risk.

Ramp-up. Moderate for a PHP team already fluent in Symfony Runtime or RoadRunner/Octane mental models — the concepts transfer. Steep for a team whose entire operational intuition is PHP-FPM: "my static variable persists across requests" is the failure mode that costs the most debugging time. Plan a half-day of team education plus a documented "no mutable statics / no request data in singletons" convention before the first production service.

Recommendation. Adopt v0.2.1 over 0.2.0 for the stable dependency alone, gate broad rollout on a successful Laravel boot spike and a soak test, and keep the blast radius to one non-critical service until a 1.0 or an explicit support commitment appears.