Repository navigation
Retry async pool acquisition in the connection factory after pool shutdown #4720
Description
Activity
- added a parent issue
on Sep 22, 2026 🔍 Triage Summary
Check Result Issue type Feature Environment N/A (feature request, not a bug report — no repro/environment fields required) Area Area\Connection PoolingDuplicates None found (closely related but not duplicative: #4714, #4718, #4719, and epic #3459) Regression Not indicated Analysis
This is a well-formed feature proposal that is part of the "Improve Async Pathways in Connectivity APIs" epic (#3459). It targets
SqlConnectionFactory's async pool-acquisition path: today, once an async wait-handle request is admitted on a pool that later gets marked retired/shut down, the request completes on that retired pool instead of retrying against the current active pool the way the synchronous path already does (per the compatibility fix in #4718). The proposal is scoped correctly to keep retry orchestration in the factory rather than having the pool call back into it, and calls out important edge cases: preserving the original timeout budget, caller cancellation, ambient transaction, and connection ownership across retries, plus bounding retries under repeated pool churn. Likely affected components:SqlConnectionFactory,ChannelDbConnectionPool,WaitHandleDbConnectionPool. Severity assessment: P2 (correctness/efficiency issue for async pool acquisition under pool shutdown races, not a crash or data-loss bug, and a conservative fallback already exists via #4718).Next Steps
- Recommend reviewing 7.1.0 regression: in-flight OpenAsync fails instantly with pool "Timeout expired" when ClearAllPools()/ClearPool() runs #4714, Preserve in-flight opens when clearing connection pools #4718, Ensure channel-pool shutdown reports shutdown rather than timeout #4719, and Improve Async Pathways in Connectivity APIs #3459 together before starting implementation, since this issue explicitly builds on the conservative fix in Preserve in-flight opens when clearing connection pools #4718 and is one of several coordinated async-connectivity follow-ups.
- Given the well-scoped design (retry ownership in the factory, no pool-to-factory callback, bounded retries, deterministic tests for both pool implementations), this is ready for implementation planning. Consider assigning to Copilot coding agent to prototype the async retry loop in
SqlConnectionFactory, mirroring the existing synchronous "pool retired → get current pool → retry" logic, and to add deterministic shutdown-before-acquisition tests for bothChannelDbConnectionPoolandWaitHandleDbConnectionPool. - Ensure any implementation explicitly avoids starting a new physical login on a pool already known to be retired, and does not attempt to cancel an in-flight physical login (per the issue's stated non-goals).
Note: This triage summary is auto-generated by an AI agent. The analysis and suggestions above have not been verified by a human maintainer. Please treat as preliminary guidance only.
Generated by SqlClient Issue Auto-Triage for #4720 · copilot · auto · 46 AIC · ⌖ 12.5 AIC · ⊞ 11.4K · ◷
🤖
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.