Doctrine Resettable Em Bundle Laravel Package

Product Decisions This Supports

• Long-running worker architecture. This bundle governs when a Doctrine EntityManager is reset between messages/jobs. That directly supports roadmap decisions about queue consumers, daemons, and batch jobs: it lets us keep processes alive for throughput without accepting unbounded memory growth or stale identity maps.
• Build vs. buy. The underlying capability is a few lines (EntityManager::clear() / reset semantics plus a listener). The buy decision is really "maintained, config-driven policy vs. hand-rolled listener code duplicated per service." 11.1.0 adding Symfony 8.1 support tilts this toward buy: we get upstream compatibility tracking for free.
• Reliability / on-call reduction. Stale-entity, detached-entity, and memory-exhausted worker failures are a recurring incident bucket. A declarative reset policy removes a class of self-inflicted bugs and makes the behavior reviewable rather than buried in per-team code.
• Platform standardization. One sanctioned reset policy across teams instead of N divergent implementations with inconsistent thresholds — a small but real consistency win in platform governance.
• Framework upgrade planning. The 11.1.0 change is a compatibility signal: it tells us the dependency is current with Symfony 8.1 and is not a blocker in the upgrade backlog.

When to Consider This Package

Consider it when:

• You run long-running PHP processes that hold a Doctrine EntityManager: Symfony Messenger consumers, queue workers, daemons, batch importers, or functional test suites that reset between tests.
• You are seeing memory growth, stale reads, or detached-entity errors in workers and want a config-driven reset (per-message vs. per-batch, thresholds) instead of bespoke listeners.
• Your platform is Symfony + Doctrine and you want maintained upstream version compatibility — 11.1.0 keeps the package on the Symfony 8.1 support matrix.
• You want reset behavior to be a shared, reviewable config surface across multiple services.

Look elsewhere when:

• The stack is Laravel/Eloquent. This is a Symfony bundle built around Doctrine's EntityManager and Symfony's DI/kernel. It is not a drop-in for Laravel. For Laravel, use the framework's own lifecycle levers: DB::purge, Model::clearBootedModels, queue --memory / --max-jobs, or worker restart strategies.
• You only serve short-lived request/response traffic — the reset never pays for itself.
• Your reset needs aren't covered (multi-connection, read/write split) and ~50 lines of owned listener code is cheaper than a bundle dependency.
• You are pinned to Symfony/PHP versions outside the 11.x support range.

How to Pitch It (Stakeholders)

For executives: This is low-cost plumbing that makes long-running background workers behave like freshly started processes. It buys down a recurring class of production failures — memory exhaustion and stale data in workers — and supports our throughput and cost-per-job goals without new infrastructure. The new release, 11.1.0, is a maintenance-compatibility update only: Symfony 8.1 support, no breaking changes, no migration work. That tells us the dependency is actively maintained and won't block our framework upgrade path. Recommend adopting where we already run Symfony/Doctrine workers; it is not applicable to our Laravel services.

For engineering: 11.1.0 is a single compatibility change — Symfony 8.1 support (PR #500) on top of 11.0.0 — with no API changes, no deprecations, and no config changes. The bump is routine and safe. The value is a standardized, config-driven reset policy in place of N hand-rolled EntityManager::clear() call sites with inconsistent thresholds, plus continued upstream support for the Symfony versions on our matrix. Be explicit about scope: this is a Symfony/Doctrine bundle, not a Laravel package — for Laravel + Eloquent services we should solve worker lifecycle with the framework's own options rather than pulling this in.