You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
When pool acquisition returns no connection because the pool was shut down, SqlConnectionFactory can retry against the current pool. Once an async request has been queued, however, its later completion does not resume that factory retry loop.
The compatibility fix in #4718 lets admitted wait-handle requests finish on the retired pool. This can start a physical login on a pool already known to be shut down, then discard the connection when it is returned.
Describe the solution you'd like
As part of #3459, let the connection factory await async pool acquisition and handle a pool-retired outcome by selecting the current active pool and retrying, matching the existing synchronous retry ownership.
Keep retry orchestration in the connection factory. The pool should report retirement without calling back into the factory.
Avoid starting a new physical login on a pool already known to be retired.
Preserve the original timeout budget, caller cancellation, ambient transaction, and connection ownership across retries.
Bound retries when pools are repeatedly cleared and keep Close/cancellation races safe.
Cover both pool implementations with deterministic shutdown-before-acquisition tests.
This does not require cancelling a physical login that is already underway.
Have the pool call the connection factory to retry. Avoid this circular dependency.
Restart OpenAsync through an internal exception signal. Prefer an awaited acquisition outcome handled by the factory instead of another retry path in SqlConnection.
Additional context
Part of #3459: Improve Async Pathways in Connectivity APIs.
Related: #4714, #4718, and #4719. This is a future async-connectivity improvement, separate from the immediate shutdown compatibility fix and the channel-pool error-classification follow-up.
🤖
Is your feature request related to a problem? Please describe.
When pool acquisition returns no connection because the pool was shut down,
SqlConnectionFactorycan retry against the current pool. Once an async request has been queued, however, its later completion does not resume that factory retry loop.The compatibility fix in #4718 lets admitted wait-handle requests finish on the retired pool. This can start a physical login on a pool already known to be shut down, then discard the connection when it is returned.
Describe the solution you'd like
As part of #3459, let the connection factory await async pool acquisition and handle a pool-retired outcome by selecting the current active pool and retrying, matching the existing synchronous retry ownership.
Close/cancellation races safe.This does not require cancelling a physical login that is already underway.
Describe alternatives you've considered
OpenAsyncthrough an internal exception signal. Prefer an awaited acquisition outcome handled by the factory instead of another retry path inSqlConnection.Additional context
Part of #3459: Improve Async Pathways in Connectivity APIs.
Related: #4714, #4718, and #4719. This is a future async-connectivity improvement, separate from the immediate shutdown compatibility fix and the channel-pool error-classification follow-up.