Resetter Bundle Laravel Package

Product Decisions This Supports

• Runtime strategy for long-running PHP: Informs whether to invest in Swoole/OpenSwoole workers, queue consumers, and daemon-style processes by supplying the connection-lifecycle hygiene those runtimes require. Without a reset layer, long-lived workers accumulate stale PDO/Redis handles and leaked transaction state.
• Build vs. buy for worker hygiene: A focused, MIT-licensed set of connection resetters is a candidate to adopt instead of writing bespoke DB::purge() / Redis reconnect logic per service. Given its immaturity (3 stars, 0 dependents), the realistic decision is "buy, vendor, and own" rather than "adopt as a supported dependency." Release 2.1.1 is a positive maintenance signal but does not change the adoption tier.
• Reliability roadmap: Directly targets a recurring incident class — "MySQL server has gone away," stale Redis connections, connections stuck in a failed transaction, and memory growth across jobs. The 2.1.1 fix confirms this incident class is real inside the reset layer itself: leftover nested transaction levels were previously not fully discarded, and connections that could not be rolled back are now closed instead of returned in an indeterminate state.
• Reset vs. restart policy: Enables a product/ops decision to reset connections between jobs rather than recycle workers on a timer, improving throughput and reducing deploy/restart overhead. Note the 2.x behavior change: in the "cannot roll back" case the connection is now closed and replaced, so a small amount of connection churn is the intended safe outcome where previously a poisoned handle could be reused.
• Standardization across services: If the team standardizes on a reset contract (Symfony's ResetInterface semantics), this bundle becomes a reference implementation the platform team can mandate for new consumers.
• Use cases to scope: queue consumers (AMQP/Kafka/Redis queues), Swoole HTTP workers, scheduled long-running daemons, and test harnesses that simulate long-lived processes.
• Laravel-specific decision: This is a Symfony bundle, not a Laravel package. The real PM decision is whether to bridge it (service provider + job middleware wrapping the resetters) or replicate the behavior with Laravel Octane's existing DB::purge / Redis::purge listeners. For most Laravel shops, the native Octane listeners are the lower-risk default and this package is a reference, not a dependency.

When to Consider This Package

Consider it when:

• You operate long-lived PHP processes (Swoole workers, message consumers, daemons) and have observed stale-connection or leaked-state failures in production — particularly failures with transaction state (nested transactions, failed rollbacks, "connection in unknown state").
• You are on Symfony, or on Laravel with a team willing to write and own a thin bridge (service provider, job/worker middleware).
• You want a small, single-purpose, MIT-licensed reset layer rather than pulling in a heavier runtime framework.
• Your team can vendor or fork a small codebase and maintain it — this is a "pilot behind a flag" dependency, not a foundation.
• You already use, or intend to use, ResetInterface-style reset semantics and want resetters that plug into that contract.

Look elsewhere when:

• Your app is standard Laravel/FPM with per-request lifecycles — the problem this solves does not exist.
• You are on Laravel Octane, which already ships listeners that purge DB and Redis connections between requests; adding this would duplicate behavior.
• You need a vendor-supported, high-adoption dependency. At 3 stars and 0 dependents it is effectively unproven; treat any adoption as an evaluation with a fallback plan.
• You need broad coverage (gRPC clients, Elasticsearch, custom SDK connection pools). Verify the resetter list first; you may end up writing most of it yourself.
• You require an SLA, security review history, or a maintainer commitment you can point auditors to.
• You cannot control the dependency version. The transaction-handling path was materially wrong until 2.1.1; environments floating on 2.1.x prior to that release carried a real correctness bug.

Release note (2.1.1): fix(dbal): discard every level of a leftover transaction, and close a connection that cannot be rolled back. Patch-level, no new APIs, no deprecations — but it is a behavioral change on the failure path (the DBAL resetter now closes an unrollbackable connection rather than passing it back). Pin the floor at >=2.1.1, re-vendor on bump, and re-run your stale-connection integration tests. Verify that application code does not cache a PDO/PHP-DBAL connection object across the reset boundary, since that handle may now be closed.

How to Pitch It (Stakeholders)

For executives: This is small, cheap insurance against a known production failure mode — stale database and cache connections in long-running PHP workers. The 2.1.1 patch is evidence the failure mode is genuine and actively maintained: it fixes incomplete cleanup of leftover nested transactions and forces closure of connections that can no longer be safely rolled back. It is MIT-licensed and narrow in scope, so cost of trial is low. The caveat remains maturity: with minimal adoption, it should be piloted behind a feature flag and treated as code we own, not a supported vendor dependency. Approve a time-boxed pilot, not a platform commitment, and require a pinned version at 2.1.1 or later.

For engineering: A Symfony bundle providing connection resetters intended to run between jobs/requests in Swoole workers and message consumers. Integration path: add the package, register the bundle/resetters at the worker boundary (after each job or request), and confirm coverage for the clients you actually use (PDO, Redis, etc.). Because it is Symfony-native, Laravel adoption requires a thin bridge — or, more pragmatically, mirroring the approach using Octane's existing purge listeners. 2.1.1 fixed a subtle defect worth understanding before you trust it: the DBAL resetter previously unwound only the outermost leftover transaction level, so a connection with nested/partial transaction state could be handed back to the pool still dirty; it now discards every level and, if rollback fails outright, closes the connection so a fresh one is established. Treat that as the baseline contract your tests should assert, not as a bonus. Mitigations: pin >=2.1.1, vendor or fork the resetters, add regression tests that simulate (a) a stale connection, (b) a nested uncommitted transaction at job end, and (c) an unrollbackable connection, and keep a manual DB::purge() / Redis reconnect fallback. Success metrics: connection-related errors per 10k jobs, worker memory growth, and worker restart frequency. Do not adopt without a named owner.