Skip to content

Retry async pool acquisition in the connection factory after pool shutdown #4720

Description

@mdaigle

🤖

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.

Describe alternatives you've considered

  • Let admitted requests finish on the retired pool and discard their connections on return. This is the conservative fix in Preserve in-flight opens when clearing connection pools #4718.
  • 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.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions