fix(data-source): prevent connection leaks in DataSource.initialize() - #12704

Description

initialize() swallows a rejection from driver.disconnect() and its finally still clears
isInitializing, leaving the data source eligible for another connection attempt even though the
prior driver resource was not released. For MySQL, a failed pool.end() leaves this.pool set
while the next connect() overwrites it with a new pool, so a cache-connect failure followed by a
cleanup error and retry loses the only handle to the old pool.

Code

packages/typeorm/src/data-source/DataSource.ts[R293-296]

+                    try {
+                        await this.driver.disconnect()
+                    } catch {
+                        // ignore

Evidence

The changed cleanup catches and discards every driver disconnection error, then clears the only
in-progress guard. MySQL only clears its pool field after pool.end() succeeds, while connect()
assigns a newly created pool to that same field; therefore retrying after a failed cleanup
overwrites the remaining reference to the prior pool.

packages/typeorm/src/data-source/DataSource.ts[241-244]
packages/typeorm/src/data-source/DataSource.ts[293-302]
packages/typeorm/src/driver/mysql/MysqlDriver.ts[378-392]
packages/typeorm/src/driver/mysql/MysqlDriver.ts[444-462]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
A failed driver cleanup is ignored while the initialization guard is cleared, allowing a retry to overwrite the handle to a driver resource that may still be open.
## Fix Focus Areas
- packages/typeorm/src/data-source/DataSource.ts[241-244]
- packages/typeorm/src/data-source/DataSource.ts[293-302]
## Recommended Fix
Record unsuccessful initialization cleanup and prevent a new driver connection until that cleanup has subsequently succeeded. Preserve the original initialization error for the first caller, but retain the cleanup failure state so retries cannot silently connect over an unreleased resource.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

initialize() reconnects through this.queryResultCache and later reads that mutable field again
when cleaning up a failed cache connection. If setOptions() replaces the cache provider while
connect() is pending, cleanup disconnects the replacement and leaves the originally connecting
provider alive.

Code

packages/typeorm/src/data-source/DataSource.ts[R286-288]

+                    if (this.queryResultCache) {
+                        try {
+                            await this.queryResultCache.disconnect()

Evidence

The connection attempt awaits the current cache field, while setOptions() can synchronously
replace that field with a newly created provider. The added catch block then reads the field again,
so it has no guarantee that it disconnects the provider whose connection failed; Redis providers
hold their client on the provider instance until that same instance is disconnected.

packages/typeorm/src/data-source/DataSource.ts[215-218]
packages/typeorm/src/data-source/DataSource.ts[255-257]
packages/typeorm/src/data-source/DataSource.ts[286-292]
packages/typeorm/src/cache/RedisQueryResultCache.ts[46-64]
packages/typeorm/src/cache/RedisQueryResultCache.ts[101-105]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`initialize()` reads the mutable `queryResultCache` field again during failure cleanup. A concurrent `setOptions()` call can replace that field while the original provider's `connect()` is pending, causing cleanup to disconnect the replacement and leak the original provider.
## Fix Focus Areas
- packages/typeorm/src/data-source/DataSource.ts[255-299]
## Recommended Fix
Capture `this.queryResultCache` in a local variable before invoking `connect()`, and use that same captured instance for both the connection attempt and pre-initialization failure cleanup. Add a regression test that replaces the configured provider while the original provider's failing connection is pending and verifies that the original provider is disconnected.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

The docs now claim initialize() “must only be called once” and that calling it again after success
rejects, but destroy() explicitly supports reopening the connection and resets isInitialized,
allowing a later initialize() to succeed. This mismatch can mislead users into thinking
reconnecting on the same DataSource is unsupported.

Code

docs/docs/data-source/1-data-source.md[R11-13]

+`initialize` must only be called once: calling it again while a previous call is still in progress, or after it has
+succeeded, rejects with a `CannotConnectAlreadyConnectedError`. If initialization fails, the partially established
+connection is cleaned up and `initialize` can safely be called again.

Evidence

The newly added docs text states repeated initialize after success rejects, but the DataSource API
explicitly allows reconnecting after destroy() by resetting isInitialized to false and noting
that you can open the connection again.

docs/docs/data-source/1-data-source.md[11-13]
src/data-source/DataSource.ts[240-305]
src/data-source/DataSource.ts[308-321]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The docs currently state `initialize()` must only be called once and that calling it again after it has succeeded rejects. In reality, calling `destroy()` resets the DataSource state and `initialize()` can be called again to reopen the connection.
### Issue Context
- `destroy()` documentation explicitly says you can open the connection again.
- `destroy()` sets `isInitialized` back to `false`, and `initialize()` only rejects when `isInitialized` or `isInitializing` are true.
### Fix Focus Areas
- docs/docs/data-source/1-data-source.md[11-13]
### Suggested change
Reword to something like:
- “`initialize()` must not be called concurrently. Calling it while initialization is in progress, or while the DataSource is already initialized, rejects with `CannotConnectAlreadyConnectedError`. After calling `destroy()`, `initialize()` may be called again to reconnect.”

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

The new concurrent-initialize test only calls destroy() when isInitialized is true, so if the first
initialize() fails before setting isInitialized the driver connection can remain open and hang the
test runner. Since destroy() throws when not initialized, add a driver.disconnect() fallback in the
finally block (guarded so it doesn’t mask the original failure).

Code

test/functional/data-source/data-source.test.ts[R124-128]

+            } finally {
+                if (dataSource.isInitialized) {
+                    await dataSource.destroy()
+                }
+            }

Evidence

The test’s finally block only destroys when isInitialized is true, but destroy() cannot be
called when initialization fails early because it throws when isInitialized is false; this leaves
no cleanup path in that scenario.

test/functional/data-source/data-source.test.ts[116-128]
src/data-source/DataSource.ts[308-317]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The new test `while initialization is in progress` only cleans up via `dataSource.destroy()` when `dataSource.isInitialized` is `true`. If `initialize()` fails before `isInitialized` is set, `destroy()` cannot be used (it throws), and the driver connection may remain open.
### Issue Context
`DataSource.destroy()` throws `CannotExecuteNotConnectedError` when `!isInitialized`, so tests that want best-effort cleanup must explicitly call `dataSource.driver.disconnect()` (preferably in a guarded `try/catch`) when `isInitialized` is false.
### Fix Focus Areas
- test/functional/data-source/data-source.test.ts[124-128]
- src/data-source/DataSource.ts[308-317]
### Suggested change
Update the test’s `finally` block to:
- `await dataSource.destroy()` when `dataSource.isInitialized`
- otherwise, best-effort `await dataSource.driver.disconnect()` inside `try/catch` to avoid masking the original test failure

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

💡 Did you know, you can route each severity your way: inline, summary, both, or drop

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗