Doctrine Reconnect Bundle Laravel Package

Product Decisions This Supports

• Queue/worker architecture: long-lived daemons vs. short-lived jobs. The package exists to keep Doctrine DBAL connections alive across idle periods in long-running PHP processes. Adopting it (or the pattern it encodes) is what lets you run persistent Messenger consumers / custom daemons without reconnecting manually — a direct input to whether "run workers as daemons" is a safe default in your architecture.
• Build vs. buy for connection resilience. The underlying fix is small (a ping-before-use check plus reconnect-on-failure around the DBAL connection). This package is a candidate "buy," but with 0 stars, 0 dependents, and a single maintainer, the honest comparison is "vendor/fork ~30–60 lines with tests" vs. "adopt an unproven dependency." The PM decision is which risk you prefer: owning a tiny piece of infra code, or inheriting an unmaintained package.
• Reducing a known incident class. If your error tracking shows recurring MySQL server has gone away / Lost connection during query after wait_timeout, this is a scoped reliability initiative with a measurable success metric: count of transient DB disconnects in worker logs trending to zero.
• Error-budget / SLO work for background processing. Failed jobs from dropped connections burn retry budgets and pollute failure dashboards. Fixing this improves the signal quality of your job-failure alerts — fewer false alarms means the real failures get attention.
• Roadmap unblocking. Any planned feature that depends on long-running DB work (bulk importers, scheduled sync jobs, outbound webhook dispatchers, pollers) inherits connection-hygiene requirements. Standardizing this now avoids each team re-solving it inside individual workers.
• Ops cost reduction. Fewer supervisor/worker restarts, less tuning of --timeout and max-job heuristics, less manual intervention in on-call.
• Vendor/dependency risk register. Even if you don't adopt it, this package is a concrete example to include in a dependency-policy discussion: what bar must a package clear before it's allowed in production?

When to Consider This Package

Consider it when all of the following hold:

• You use Doctrine DBAL — i.e., a Symfony/Doctrine stack or Laravel with Doctrine ORM. This is a Symfony bundle, not a Laravel-first package; if you're on Eloquent, it doesn't apply and the equivalent fix belongs in your queue worker's connection handling instead.
• You run long-lived CLI processes that hold a DB connection across minutes of idle time (queue consumers, daemons, schedulers, socket workers).
• You have observed evidence of idle-timeout disconnects, not a hypothetical. Otherwise you're adding a dependency to solve a problem you don't have.
• The fix is easily contained: one connection wrapper, testable, and removable without touching domain code.

Look elsewhere — or implement in-house — when:

• Laravel/Eloquent is your data layer, or you're on a Doctrine version whose reconnect semantics this bundle doesn't match. Verify compatibility against your DBAL version before any commitment; DBAL's connection/reconnect APIs have changed across majors.
• Dependency hygiene matters more than speed. Zero stars, zero dependents, one maintainer, no evidence of production users means no security response path, no compatibility guarantees, and no community to absorb maintenance if the author stops. For a package this small, "vendor it or write it" is usually the better call.
• A connection proxy (ProxySQL, pgBouncer) or your platform's managed-connection layer already solves timeouts at the infrastructure level — that's a stronger, language-agnostic fix.
• You can address it with worker-loop hygiene (bounded job batches, periodic worker recycling) — cheap, no new dependency, and often sufficient.

PM note: this bundle is a pattern delivery vehicle, not a strategic platform dependency. The sensible default is to treat it as a reference implementation: read it, write the equivalent in your own codebase with tests, and keep the option to swap in a maintained package later.

How to Pitch It (Stakeholders)

To executives (30 seconds): "We have a recurring class of background-job failures caused by database connections timing out while workers sit idle. It's not a customer-facing outage, but it creates retry noise, pollutes our failure dashboards, and occasionally costs us a delayed batch. There's an open-source package that addresses exactly this. However, it's unmaintained and has essentially no adoption, so my recommendation is not to take a dependency on it — instead, we spend roughly a day implementing the same pattern internally with tests. Same reliability outcome, no vendor risk. Success looks like: transient DB disconnects in worker logs drop to near zero, and failed-job alerts become trustworthy again."

To engineering leads: "This targets 'MySQL server has gone away' in long-lived Doctrine consumers by keeping the connection healthy across idle periods. The package is a Symfony bundle from a single author with no dependents — fine as a reference, risky as a dependency. Proposal: spend a short spike reviewing the approach, implement it as a small internal connection wrapper in our worker bootstrap, cover it with an integration test that simulates a dropped connection, and keep it behind one seam so we can replace it. If a well-maintained option emerges later, swapping is a one-file change."