Doctrine Reconnect Bundle Laravel Package

Technical Evaluation

Architecture fit

• The package is a Symfony bundle, not a Laravel package. Its entry point is a Symfony Bundle class plus a DI extension/compiler pass, which has no direct analogue in Laravel's service-provider model. It cannot be installed and used as-is in a Laravel application.
• Its actual value is the reconnect logic against Doctrine DBAL, most likely an event subscriber or connection wrapper that detects a dropped connection (MySQL 2006 server has gone away, 2013 lost connection, Postgres terminating connection) and re-establishes it before/on the next query.
• That logic is only relevant to a Laravel codebase if we are running laravel-doctrine/orm or DBAL directly. A standard Eloquent-only Laravel app gets no architectural fit at all — the equivalent capability already exists via DB::reconnect(), DB::purge(), and Octane's connection-reset listeners.
• Even in a Doctrine-based Laravel app, the bundle's Symfony wiring is dead weight; only the kernel (a few classes) would be reusable.

Integration feasibility

• Feasible only as a fork-and-extract, not as a dependency. Expect to vendor 1–3 classes and re-implement the Symfony-specific registration as a Laravel service provider plus a queue/Octane lifecycle hook.
• Blockers to confirm before committing: the bundle's composer.json constraints (PHP, doctrine/dbal 3.x vs 4.x, symfony/* 5/6/7), whether it targets Doctrine\DBAL\Connection or the older Doctrine\DBAL\Driver, and whether it relies on Symfony events that Laravel does not dispatch.

Technical risk

• Adoption risk: severe. 0 stars, 0 dependents, 0 score. There is no community validation, no downstream users to surface bugs, and a single-maintainer bus factor. This should be treated as unmaintained source material, not a supported dependency.
• Supply-chain risk: no evidence of CI, tests, security policy, or release cadence. We would be pulling unreviewed code into the data-access path — the highest-blast-radius layer of the application.
• Correctness risk (the important one): automatic reconnection on a live connection is dangerous if it fires inside an open transaction. A silent reconnect discards the transaction; the next statement runs in autocommit and can commit partial work. Any fork must refuse to reconnect when Connection::isTransactionActive() is true and instead surface the error.
• Root-cause masking: reconnect treats a symptom. Idle-connection drops are usually better solved by tuning wait_timeout, max_lifetime, TCP keepalives, or the pooler, not by retry logic.

Key questions

1. What exactly does it hook — DBAL event subscriber, driver middleware, or a Connection decorator? Does the same instance stay registered in the container, or does it need a wrapper?
2. What is its transaction behavior on reconnect? Does it re-raise, retry, or silently continue?
3. Which DBAL/PHP/Laravel-compatible Doctrine versions are supported, and what license applies to a fork?
4. Does it handle read/write splitting (PrimaryReadReplicaConnection) and prepared-statement/statement-cache invalidation?
5. Is there any test suite, and does it cover the reconnect path with a real dropped connection?
6. Is the project archived? Last commit date and open-issue count matter more than star count here.

Integration Approach

Stack fit

• Applicable only if the target Laravel app speaks Doctrine/DBAL. Confirm this first; if the app is Eloquent-only, stop and implement the native alternative.
• The genuine native equivalent for Laravel:
  • Queue workers: reconnect in a JobProcessing/Looping listener, or rely on DB::reconnect() before each job.
  • Octane: register connection purge/reset in the RequestTerminated/TaskTerminated listeners.
  • Long-running console commands: call DB::reconnect() at the top of each batch iteration.
• For Doctrine-backed apps, the fork becomes a small ReconnectServiceProvider that decorates Doctrine\DBAL\Connection and exposes the same guard.

Migration path

1. Spike (1–2 days): clone the repo, read the kernel, write a failing test that kills the connection server-side and asserts a retry succeeds and a transaction retry fails loudly.
2. Fork: vendor into app/Support/Doctrine/Reconnect (or an internal Composer path repo) with attribution and the original license. Strip all Symfony DI code.
3. Wrap: implement a Laravel service provider binding the decorated connection, plus lifecycle hooks for queues and Octane.
4. Replace, don't depend: keep nalogka/doctrine-reconnect-bundle out of composer.json entirely so upstream deletion cannot break our build.

Compatibility

• Pin to the DBAL major version we actually run; DBAL 4 changed Connection internals materially versus 3.x, and a bundle last touched on DBAL 3 will not port cleanly.
• Verify PHP 8.2/8.3 compatibility and Laravel 10/11/12 support of the surrounding Doctrine bridge before scheduling work.

Sequencing

• Start with queue workers and console commands — that is where connection drops actually occur and where the blast radius of a bad reconnect is contained.
• Do not enable it for HTTP requests until Octane behavior is understood; under FPM the connection lifecycle is per-request and the package is largely pointless.

Operational Impact

Maintenance

• Effectively zero upstream maintenance guarantee. With 0 stars and 0 dependents, we should assume the repo may be archived or deleted. Forking is mandatory, and the fork becomes our code to own forever.
• Ongoing cost is low in lines-of-code but non-zero in ownership: every DBAL upgrade requires re-validating our reconnect decorator.

Support

• No vendor, no community, no documented SLA. Internal on-call owns all failures. Escalation path is "read the fork," which is acceptable only because the surface area is small.

Scaling

• Reconnect itself is cheap, but it can produce a reconnect storm: on a database failover or network blip, every worker and Octane process reconnects simultaneously, spiking connection churn and potentially exhausting max_connections.
• Needs jittered backoff and a per-process cap on reconnect attempts. The bundle almost certainly ships neither.

Failure modes

• Silent transaction loss — the highest-severity risk; partial writes committed in autocommit after a mid-transaction reconnect.
• Duplicate side effects — a job that reconnects and retries after an unacknowledged commit can double-write.
• Stale prepared statements / statement cache after reconnect.
• Masked infrastructure faults — flaky networking or an undersized wait_timeout never gets fixed because the app "self-heals."
• Read-replica staleness if the reconnect lands on a replica in a split setup.

Ramp-up

• Low code volume, but high context requirement: engineers need working knowledge of Doctrine DBAL connection internals, Laravel's container binding, queue worker lifecycle, and Octane's sandbox reset. Budget roughly 1–2 engineer-days for the spike and 3–5 for a tested internal version.
• Recommendation: do not adopt the package. Use it as a reference implementation for an in-house, transaction-safe reconnect guard built on Laravel's native DB::reconnect() and lifecycle events.