Roadrunner Bridge Laravel Package

Technical Evaluation

Architecture fit: Unchanged at the architectural level. The v4.0.0 release does not alter the core premise — RoadRunner's Go server fronting persistent PHP workers, with the bridge supplying Laravel-compatible bootstrapping in place of the per-request public/index.php lifecycle. The state-management caveats (long-lived workers, static caches, connection reuse) remain the dominant design consideration. What the release does change is the surface area of the bridge itself: logging and worker-lifecycle plumbing are the primary interfaces a TPM will touch during integration, and both moved in this release.

Integration feasibility: Still feasible via Composer plus RoadRunner binary and YAML config, but v4.0.0 raises the integration cost in two specific places:

• Logger configuration is now a moving target. PRs #109, #112, #114, #120, and #123 collectively rework the PSR-3/RoadRunner log handler: Alert and Emergency level mapping corrected, bubble and log-level semantics adjusted, log output normalized, and slash/Unicode escaping removed. Existing logging.php / RoadRunner YAML handler configs should be assumed non-portable until verified.
• Interceptors changed shape. #119 normalizes TCP and Centrifugo interceptor arguments, which is an argument-shape change for anyone wiring interceptors directly.
• Graceful shutdown improved. #118 fixes EXIT command handling — directly relevant to the worker lifecycle concerns flagged in the prior assessment, since clean worker exit is a prerequisite for predictable state teardown.

Technical risk: Risk is raised to high, driven by the major-version semantics rather than by any single fix:

• #115 "Make implementations internal" is the headline risk. Classes previously usable/extendable are now @internal, meaning SemVer explicitly no longer protects them. Any code extending, decorating, or type-hinting those implementations is now on an unsupported path and can break in minor releases going forward.
• #121 "Remove deprecations" is a confirmed breaking change; deprecated APIs removed with no deprecation window remaining.
• #118 EXIT command fix implies past versions mishandled worker shutdown — worth treating as a latent reliability bug in v3.x that this release corrects, not just a feature.
• Log normalization + escaping changes (#120, #123) can silently alter downstream log parsing, alert rules, and dashboards — a low-severity code change with potentially high-severity operational blast radius.
• The prior assessment's transparency concern is partially mitigated: nine PRs across six contributors including four first-time contributors, with an explicit changelog diff, indicates an active maintenance cadence. Community health is better than "unknown" implied.

Key questions:

• Is there a documented BC-break list or upgrade guide for 3.6 → 4.0, specifically enumerating which classes became @internal and which deprecated APIs were removed?
• What Laravel versions and PHP extensions are officially supported on v4.0.0? (Still unanswered from the prior review.)
• How does the bridge handle database connection resets between requests? (Still unanswered.)
• Does the bubble / log-level rework change the format of emitted log lines, or only routing and escaping? This determines whether log-based alerting needs re-tuning.
• Are the normalized TCP/Centrifugo interceptor arguments a rename, a reorder, or a type change — and is there a shim?
• Is the EXIT command fix relevant only to RoadRunner worker shutdown, or does it also affect Laravel queue worker and console command exit paths?
• Are there known conflicts with common Laravel packages (session handlers, debug bars, Horizon, Telescope) under persistent workers?

Integration Approach

Stack fit: Neutral-to-positive. The release hardens observability and shutdown behavior — exactly the two areas that most often sink persistent-worker migrations in production. Nothing in v4.0.0 argues against the RoadRunner approach; several things argue for waiting until the internal/deprecation changes are characterized.

Migration path: Treat this as a re-baseline, not an upgrade. Because implementations are now internal and deprecations are gone, downgrade-and-retry is not a safe rollback strategy. Recommended path:

1. Freeze new integration work on v3.6.x momentarily and inventory the codebase for (a) any class inherited or decorated from the bridge, (b) any use of APIs deprecated in 3.x, (c) all RoadRunner logger handler config, (d) all interceptor wiring.
2. Prototype on v4.0.0 in an isolated branch; the inventory in step 1 is the test checklist.
3. Adopt v4.0.0 as the first production version if integration has not yet shipped — there is no migration debt to pay, and you get the EXIT fix and corrected log levels for free.
4. If already on 3.6.x in production, sequence the log-format verification before the version bump, not after.

Compatibility: Pin ^4.0 explicitly; do not allow >=3.6 ranges that could straddle the internal/deprecation boundary. Expect to pin exact minor versions once internal classes are in use adjacent to your code, since SemVer no longer covers those paths. Framework-version compatibility remains unverified — confirm before committing.

Sequencing: (1) Audit deprecated/internal usage → (2) validate logger output format in staging against existing alert rules → (3) verify interceptor argument changes → (4) confirm graceful shutdown under load → (5) cut over. Steps 2 and 4 are the gating items; they carry operational risk disproportionate to their code diff.

Operational Impact

Maintenance: The @internal designation shifts a real maintenance burden onto your team. Anything extending bridge implementations becomes effectively vendored — you own it, and RoadRunner's maintainers may change it without notice. Budget for periodic diff reviews of the bridge source before each minor bump, not just each major. Upside: an active maintainer group and a first-time-contributor pipeline suggest the package is being invested in rather than coasting.

Support: Improved versus the prior assessment. Named contributors with linked PRs and a full changelog diff is a materially better support posture than the previously noted "unknown" repository state. Still no evidence of an SLA, LTS policy, or security disclosure process — for a component sitting in the request path of every HTTP call, that gap should be documented as an accepted risk rather than assumed away.

Scaling: No change to the scaling model; persistent workers still deliver the bootstrap-overhead win for high-throughput APIs. The EXIT command fix modestly improves scaling behavior by making worker recycling and graceful shutdown more reliable — relevant under autoscaling and rolling deploys, where a worker that fails to exit cleanly becomes a stuck pod or a dropped in-flight request.

Failure modes: The risk profile is now more legible and, in places, more benign:

• Corrected: misrouted Alert/Emergency logs (previously a silent loss of the highest-severity events — a genuine monitoring blind spot now closed), and mishandled EXIT commands.
• Newly introduced: log-format drift breaking parsers, dashboards, and alert rules; interceptor argument mismatches failing at boot; and — the durable one — silent breakage from internal APIs changing in a patch or minor release, which manifests as a runtime error rather than a Composer conflict.
• Unchanged: shared-state leakage between requests, stale database connections, memory growth over long-lived workers, and third-party package incompatibility with persistent lifecycles.

Ramp-up: Slightly steeper than the prior assessment suggested. Engineers must learn not just the persistent-worker mental model but also a discipline of checking whether a bridge class is @internal before building on it. The logging rework adds a small but non-zero learning cost around bubble/log-level semantics that most teams will not have encountered before. Mitigate with a short internal note on the internal-API policy and the log-format contract, and treat both as review checklist items.