Resetter Bundle Laravel Package

Technical Evaluation

Architecture fit. The package addresses a real and growing failure mode in long-running PHP: stale TCP sockets, dropped DB connections, expired Redis/AMQP sessions, and leaked request state after fork() or idle periods. Architecturally, a "resetter" abstraction (a registry of reset() callables invoked at worker lifecycle boundaries) is the correct shape for this problem — it is small, composable, and orthogonal to business logic.

The critical caveat for a TPM: this is a Symfony bundle, not a Laravel package. It is part of the symfony-swoole ecosystem and will wire itself through Symfony's DI container, EventDispatcher, and compiler passes. Our stack is Laravel. Nothing here is drop-in; the value is the design pattern and the individual resetter implementations, not the package itself.

Update (2.1.1). The patch is a targeted correctness fix in the Doctrine DBAL resetter: it now unwinds every nesting level of a leftover transaction and, when a connection cannot be rolled back, closes it outright rather than returning it to the pool in an indeterminate state. Two things follow. First, upstream is demonstrably maintained and is reasoning about the exact failure class we flagged as our top risk — that is a positive signal for the reference implementation's quality. Second, it confirms that the naive version of this resetter (the one we would most likely have written ourselves) is genuinely wrong in a way that is invisible in normal testing. The pattern is still correct; the implementation detail is where the hazard lives.

Integration feasibility. Low as a dependency, moderate as a reference implementation. With 3 stars, minimal dependents, and a single-vendor namespace, taking a hard Composer dependency on it in a production Laravel app is not defensible. What is feasible is:

• Read the resetters (Doctrine DBAL transaction unwinding + ping(), Redis PING, AMQP heartbeat, possibly PDO handle validation) and port them into a Laravel service provider that hooks Octane worker events (WorkerStarting, WorkerStopping, RequestTerminated) and queue events (JobProcessing, JobProcessed, WorkerLooping).
• Estimated porting effort revised upward to 2–4 engineer-days: the transaction-level handling in 2.1.1 is not a DB::purge() one-liner. Faithful porting requires reading DB::transactionLevel(), rolling back to level 0, and disconnecting when that fails — plus tests that deliberately strand a nested transaction and assert the connection is discarded, not reused.

Technical risk.

• Ecosystem mismatch — no Laravel container bindings, no config/ publishing, no facades; Symfony-specific glue must be discarded.
• Bus factor — single-vendor, near-zero adoption, no community signal to validate correctness against edge cases. Mitigated slightly by 2.1.1: the PR link and named author show a review process, not a drive-by dump.
• Release provenance — verify the release is a real tagged artifact before relying on versioning guarantees. Note the 2.1.0 → 2.1.1 delta implies a real defect shipped in a safety-critical path; treat pre-2.1.1 behavior as known-bad and do not reference 2.1.0 code when porting.
• Silent-failure risk — resetters that "succeed" without actually re-establishing a connection are worse than none; naive PING-based liveness checks can mask pool exhaustion. 2.1.1's "close if not rollbackable" is exactly the escalation behavior we should copy; anything that swallows a failed rollback is a bug.
• MIT license — permissive, so vendoring or forking into an internal package is legally clean.

Key questions.

1. Which connection types does it actually reset today (PDO/MySQL, PostgreSQL, Redis, AMQP, Memcached, HTTP clients), and are connection pools handled or only single connections?
2. Does it reset at request/job boundaries only, or does it expose a policy for idle-timeout and pre-execution health checks?
3. Partially answered by 2.1.1: on a DBAL reset, it rolls back all transaction levels, and if rollback fails it closes the connection. Remaining unknown: what it does when the rollback loop itself throws mid-way, and whether that surfaces, logs, or is swallowed.
4. Is there a documented contract (ResetterInterface) stable enough to depend on if we fork?
5. What is the maintenance posture of the upstream org — 2.1.1 suggests active, but confirm symfony-swoole releases on a cadence and that this is not an internal extraction published for convenience.

Integration Approach

Stack fit. Treat this as pattern source, not a dependency. Our target surfaces are Laravel Octane (Swoole/RoadRunner/FrankenPHP workers) and Laravel Horizon/queue workers — both are exactly the long-running contexts the package was designed for. Laravel gives us the lifecycle hooks; we supply the reset logic ourselves.

Migration path.

1. Spike (1 week, 1 engineer). Vendor the repo read-only into a sandbox, inventory every resetter, and map each to a Laravel equivalent (DB::purge(), Redis::connection()->client()->ping(), Queue::connection()->reconnect(), HTTP client pool flush). Port specifically from 2.1.1 or later.
2. Internal package. Publish acme/long-running-resetters with a ResetterInterface, a tagged registry, and a config file declaring which connections to guard. Credit upstream under MIT. Include the transaction-depth handling as a first-class requirement, not a follow-up: roll back to level 0, then disconnect() on failure.
3. Wire to lifecycle. Register resetters on Octane WorkerStarting/RequestTerminated and on Horizon JobProcessing (guarded by a "resetter ran within N seconds" throttle so we don't pay a round-trip per job).
4. Retire the upstream reference from the repo; keep the attribution and the link in the internal README for future re-syncs.

Compatibility. Laravel 10/11/12 differ in Octane event naming and queue connection APIs; the internal package should target the two versions we actually run and declare that explicitly. Because we control the code, driver variance (MySQL vs. Postgres vs. Redis Cluster) becomes our test matrix rather than an unowned upstream risk. Note that nested-transaction semantics differ between MySQL and Postgres (savepoints), so the rollback-to-level-0 logic needs a per-driver test, not a single happy-path test.

Sequencing. Do not couple this to an Octane migration. Ship it after the app is running on Octane and has demonstrated at least one stale-connection incident — that gives us a reproduction and a measurable success criterion before we add lifecycle machinery. The 2.1.1 fix is a useful forcing function: it tells us the test we must write (strand a nested transaction, assert the connection is dropped).

Operational Impact

Maintenance. Owning a fork means we own the reset semantics for every driver version we bump. That is roughly a few hours per quarter, but it is real and should be assigned, not assumed. The low code surface keeps this cheap — the risk is not complexity, it is neglect. 2.1.1 is a reminder that upstream can change semantics in a patch release; we should re-read the changelog before any re-sync, not merge it blind.

Support. No vendor SLA, no community. Escalation is "read the source," which is acceptable at this size but must be a conscious decision. If a resetter is subtly wrong and corrupts a connection state, we debug it ourselves.

Scaling. Resetters do not scale with traffic — they scale with worker count and connection pool size. At high worker counts, naive per-job PING checks add meaningful round-trip load; the throttle/backoff policy matters more than the reset logic itself. Note that 2.1.1 introduces a path that closes connections rather than recycling them; if that path triggers broadly (e.g. during a database failover), it converts a partial degradation into a full pool drain. Verify that reconnect storms don't create a thundering herd against the database.

Failure modes to design for.

• False negative — resetter passes, connection is still dead; job fails on first query.
• Transaction violation — reset mid-transaction silently discards work; must be a no-op outside job boundaries. 2.1.1 shows the correct handling: unwind every level, then close if that fails. Our port must replicate this or we reintroduce a known bug.
• Thundering herd — synchronized reconnects after idle or failover; heightened by the new connection-closing behavior.
• Masked leaks — resetters fix the symptom; they do not fix the underlying connection leak or missing finally block.
• Double-reset — both the framework (Octane) and our package acting on the same connection.

Ramp-up. Low. A mid-level engineer can absorb the concept in a day. The onboarding cost is not the code, it is the operational intuition: when to reset, how often, and how to tell a reset apart from a genuine outage. Budget for a short written runbook and one dashboard panel tracking reset frequency, connection-close count, and post-reset error rate — that is what turns this from a hack into an operable component.

Recommendation. Do not adopt as a dependency. Extract the resetter designs — from 2.1.1 or later — into an internal Laravel package, scoped to Octane and queue workers, gated behind a lifecycle-event throttle, with explicit transaction-unwinding and connection-close behavior. Net cost is small; net risk of not doing it is intermittent, hard-to-reproduce production failures as our long-running workload grows.