Ensure channel-pool shutdown reports shutdown rather than timeout

[mdaigle]

🤖

Describe the bug

Please verify that acquisitions interrupted by ChannelDbConnectionPool shutdown report shutdown rather than a pool timeout, and correct any paths that misclassify the failure.

This is a focused follow-up to #4714. PR #4718 addresses the wait-handle pool only.

Current evidence: ChannelDbConnectionPool.GetInternalConnection already catches ChannelClosedException and throws InvalidOperationException with SQL_ConnectionPoolShutDown: “The connection pool has been shut down.” Its OperationCanceledException handler reports ADP.PooledOpenTimeout(). A channel-pool timeout misclassification has not yet been reproduced.

Source: ChannelDbConnectionPool.cs.

To reproduce

No confirmed channel-specific repro yet. Please add deterministic coverage with Switch.Microsoft.Data.SqlClient.UseConnectionPoolV2 enabled:

1. Hold all available pool capacity and park another acquisition.
2. Call ClearPool or ClearAllPools before its connection timeout expires.
3. Verify the acquisition reports shutdown, not a pool timeout.

Cover both Open and OpenAsync, including shutdown while an async acquisition is scheduled but has not started. Keep separate coverage for genuine timeout expiration and caller cancellation.

The workload in #4714 can also guide investigation with the channel-pool switch enabled.

Expected behavior

• Shutdown-interrupted acquisitions report the existing shutdown-specific error rather than suggesting pool exhaustion or an elapsed timeout.
• Genuine timeouts retain their timeout error.
• Caller cancellation retains its existing behavior.

If all relevant paths already behave correctly, add regression coverage and document that finding rather than changing the error handling unnecessarily.

Further technical details

Microsoft.Data.SqlClient version: current source at 153f8793e6672816ce6a0652fdae4ea21708b5ad; affected released versions not established.
.NET target: not yet reproduced.
SQL Server version: not yet reproduced.
Operating system: not yet reproduced.

Additional context

Related: #4302, #4714, #4718.

Scope is error classification and regression coverage only. Allowing admitted channel-pool acquisitions to finish after shutdown, adding replacement-pool retries, and redesigning channel lifetime are out of scope.

[github-actions]

🔍 Triage Summary

Check	Result
Issue type	Task (investigation/verification follow-up, not a reported bug)
Environment	Not applicable — this is a self-scoped investigation task, not a customer bug report; author explicitly notes ".NET target: not yet reproduced", "SQL Server version: not yet reproduced", "Operating system: not yet reproduced" pending investigation
Area	Area\Connection Pooling
Duplicates	None found as exact duplicates. Directly related: #4714 (regression report), #4718 (fix PR for the wait-handle pool), #4302 (original pool redesign)
Regression	Related to the 7.1.0 regression tracked in #4714 (in-flight OpenAsync reporting Timeout expired instead of shutdown when ClearAllPools()/ClearPool() runs). This issue narrows that investigation to the ChannelDbConnectionPool (Switch.Microsoft.Data.SqlClient.UseConnectionPoolV2) path specifically, since PR #4718 only fixed the wait-handle pool.

Analysis

This issue asks for verification that ChannelDbConnectionPool correctly reports SQL_ConnectionPoolShutDown (not a timeout) when an in-flight acquisition is interrupted by ClearPool/ClearAllPools, mirroring the fix already applied to the wait-handle pool in #4718. The reporter notes the existing ChannelClosedException/OperationCanceledException handling in ChannelDbConnectionPool.GetInternalConnection looks correct on inspection, but no channel-pool-specific repro has been confirmed yet — so this is investigation + regression-test work, not a confirmed defect. Likely affected component: ConnectionPool/ChannelDbConnectionPool.cs. Severity: P2 (narrow, well-scoped follow-up to a known regression area; channel pool is opt-in via an AppContext switch, limiting blast radius).

Next Steps

• Recommend assigning this issue to Copilot coding agent to write deterministic repro/regression tests for ChannelDbConnectionPool with Switch.Microsoft.Data.SqlClient.UseConnectionPoolV2 enabled, covering: (1) Open and OpenAsync acquisitions in-flight during ClearPool/ClearAllPools, (2) shutdown while an async acquisition is scheduled but not yet started, and (3) confirming genuine timeout and caller-cancellation paths are unaffected — per the exact scenarios called out in the issue body.
• If the existing ChannelClosedException/OperationCanceledException handling in GetInternalConnection (lines ~1593-1605) is confirmed correct under test, add the regression coverage and close as "verified, no code change needed" rather than altering error handling speculatively.
• Before starting, review 7.1.0 regression: in-flight OpenAsync fails instantly with pool "Timeout expired" when ClearAllPools()/ClearPool() runs #4714 and PR Preserve in-flight opens when clearing connection pools #4718 to reuse the same test harness/workload pattern for consistency between the wait-handle and channel pool test suites.

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 #4719 · copilot · auto · 81.8 AIC · ⌖ 12.5 AIC · ⊞ 11.4K · ◷