Weave Code
Resetter Bundle Laravel Package
swoole-bundle/resetter-bundle
Resetter bundle for Swoole Bundle that clears Symfony service and container state between requests in long-running workers, preventing state from leaking across requests so applications stay consistent under Swoole.
Symfony bundle with resetters for various connections, e.g. doctrine/dbal and phpredis.
Frequently asked questions about Resetter Bundle
- What does swoole-bundle/resetter-bundle do?
- It is a Symfony bundle for applications running under Swoole workers that resets services and container state after each handled request. It integrates with the Swoole request lifecycle and invokes a registry of reset callables so managers such as Doctrine do not carry stale state into the next request. The goal is preventing cross-request data leakage in persistent-runtime apps.
- Can I install swoole-bundle/resetter-bundle in a Laravel app with Composer?
- You can require it with Composer, but it will not wire itself into Laravel. It is a Symfony bundle that registers through Symfony's DI container, EventDispatcher, and compiler passes, so there are no Laravel container bindings, config publishing, or facades. Treat it as a reference implementation rather than a drop-in dependency.
- Does this package support Laravel Octane?
- No. It is built for the symfony-swoole ecosystem and hooks the Swoole request lifecycle through Symfony bundle glue, not Octane's worker events. To use the ideas in Laravel you would port the resetters into a service provider listening for WorkerStarting, WorkerStopping, RequestTerminated, and queue events. The porting effort is estimated at two to four engineer-days because transaction handling is not a one-liner.
- How does the resetter prevent state leaking between Swoole requests?
- It keeps a registry of reset callables and runs them at worker lifecycle boundaries after a request has been handled. Each resetter returns a service or manager to a known-clean state, for example unwinding leftover transactions and revalidating a database connection. Because the logic is orthogonal to business code, you can add or remove resetters without touching controllers or services.
- Which connections does it reset today, Doctrine, Redis, or AMQP?
- The documented scope is configurable reset strategies for Doctrine and other managers, and version 2.1.1 specifically hardens the Doctrine DBAL resetter. Resetters for Redis PING, AMQP heartbeat, and PDO handle validation are the kind of implementations you should verify in the source before relying on them. Audit the actual resetter list rather than assuming pool-aware coverage for every connection type.
- What changed in version 2.1.1 and should I avoid 2.1.0?
- 2.1.1 is a correctness fix in the Doctrine DBAL resetter: it unwinds every nesting level of a leftover transaction and, if rollback fails, closes the connection instead of returning an indeterminate one to the pool. That implies 2.1.0 shipped a real defect in a safety-critical path. Treat pre-2.1.1 behavior as known-bad and do not copy 2.1.0 code when porting.
- How do I configure reset strategies for Doctrine in Symfony?
- Configuration is handled through the Symfony bundle's DI extension, so you enable the bundle and adjust its reset strategy options in your Symfony config. The exact keys are not covered in the package overview, so check the bundle's README and config definition for the Doctrine manager options. The key behavior to preserve is escalating to a connection close when a rollback cannot be completed.
- Is it safe to use in production when it only has 3 GitHub stars?
- Taking a hard Composer dependency on a single-vendor package with three stars and minimal dependents is not defensible for a production Laravel app. The MIT license makes vendoring or forking into an internal package legally clean if you want the implementations. The 2.1.1 release does show a review process and active maintenance, which is a positive signal for the reference implementation's quality.
- How do I test that resetters actually reconnect instead of silently succeeding?
- Deliberately strand a nested transaction, trigger the resetter, and assert that the connection is discarded rather than reused. A resetter that reports success without re-establishing a connection is worse than none, and naive PING liveness checks can mask pool exhaustion. Copy the escalation behavior from 2.1.1: anything that swallows a failed rollback is a bug.
- What are the alternatives for resetting state in Laravel long-running workers?
- For Laravel you would normally build a small service provider around Octane and queue worker events and implement the resetters yourself, using DB transaction-level checks and connection purges. Porting the Doctrine transaction unwinding, Redis PING, and AMQP heartbeat patterns from this bundle is the realistic path. There is no Laravel-native replacement in this package because it has no Laravel integration at all.
Weaver
How can I help you explore Laravel packages today?