Fix async cancellation failing to send TDS attention signal

.editorconfig

@@ -197,4 +197,8 @@ dotnet_diagnostic.CA1416.severity = silent
 
 dotnet_code_quality.CA2100.excluded_type_names_with_derived_types = Microsoft.Data.SqlClient.ManualTesting.Tests.*
 dotnet_diagnostic.xUnit1031.severity=none
-dotnet_diagnostic.xUnit1030.severity=none
+dotnet_diagnostic.xUnit1030.severity=none
+
+# Pool pruning leases must be disposed or explicitly handed off.
+[src/Microsoft.Data.SqlClient/src/Microsoft/Data/SqlClient/ConnectionPool/**/*.cs]
+dotnet_diagnostic.CA2000.severity = warning

.github/ISSUE_TEMPLATE/bug-report.md

@@ -2,7 +2,7 @@
 name: Bug report
 about: Create a report to help us improve
 title: ""
-labels: [":new: Triage Needed", ":bug: Bug!"]
+type: Bug
 assignees: []
 
 ---

.github/ISSUE_TEMPLATE/code_review_skill_drift.yml

@@ -0,0 +1,88 @@
+name: Code Review Skill Drift
+description: Record something a review learned that the sqlclient-code-review skill got wrong, missed, or no longer matches
+title: "[review-skill] "
+labels: ["Area\\Engineering"]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        For observations about `.github/skills/sqlclient-code-review/` itself, not about the code under review.
+        File one issue per observation so each can be judged on its own evidence.
+
+        **Redact** connection strings, passwords, tokens, customer data, and non-public source from every field, including commands, output, and diff excerpts.
+
+        **Security vulnerabilities:** do not report them here, even redacted. Use the private MSRC process in [SECURITY.md](https://github.com/dotnet/SqlClient/blob/main/SECURITY.md).
+
+  - type: dropdown
+    id: class
+    attributes:
+      label: Drift class
+      options:
+        - Wrong finding - raised, then retracted or downgraded after checking
+        - Missed defect - the skill should have caught it and did not
+        - Stale fact - a path, check, filter, or policy in the skill no longer matches the repo
+        - Wasted step - cost review time without changing the outcome
+        - Mechanizable - a recurring finding a lint, analyzer, test, or CI check could catch
+    validations:
+      required: true
+
+  - type: input
+    id: source
+    attributes:
+      label: Where it happened
+      description: PR, review thread, or comment URL. For a local review, give base and head commit IDs.
+    validations:
+      required: true
+
+  - type: textarea
+    id: says
+    attributes:
+      label: What the skill says today
+      description: Quote the line or section, or say that nothing covers this.
+    validations:
+      required: true
+
+  - type: textarea
+    id: observed
+    attributes:
+      label: What actually turned out to be true
+      description: The observation, in terms a future reviewer would need.
+    validations:
+      required: true
+
+  - type: textarea
+    id: evidence
+    attributes:
+      label: Evidence
+      description: Redacted `file:line`, command and output, spec section, or the thread where it was settled.
+    validations:
+      required: true
+
+  - type: dropdown
+    id: cost
+    attributes:
+      label: What it cost
+      options:
+        - A retracted P1 or P2 finding
+        - A retracted or downgraded P3 finding or question
+        - A defect reached a shipped branch
+        - Review time only
+        - Nothing yet - noticed before it mattered
+    validations:
+      required: true
+
+  - type: textarea
+    id: recurrence
+    attributes:
+      label: Prior occurrences
+      description: Links to earlier instances, if known. Recurrence is what promotes an entry.
+    validations:
+      required: false
+
+  - type: textarea
+    id: proposal
+    attributes:
+      label: Proposed change
+      description: Optional. Name the section and what it replaces. If a check would catch it instead, name the check.
+    validations:
+      required: false

.github/ISSUE_TEMPLATE/feature_request.md

@@ -2,7 +2,7 @@
 name: Feature request
 about: Suggest an idea for this project
 title: ""
-labels: [":new: Triage Needed", ":bulb: Enhancement"]
+type: Feature
 assignees: []
 
 ---

.github/copilot-instructions.md

@@ -11,9 +11,9 @@
 
 ## 📚 Project Overview
 This project is a .NET data provider for SQL Server, enabling .NET applications to interact with SQL Server databases. It supports various features like connection pooling, transaction management, and asynchronous operations.
-The project builds from a **single unified project** at `src/Microsoft.Data.SqlClient/src/Microsoft.Data.SqlClient.csproj`. It targets `net8.0` and `net9.0` on all supported hosts, and adds `net462` only when building on Windows. The legacy `netfx/` and `netcore/` directories are being phased out — only their `ref/` folders (which define the public API surface) remain active.
+The project builds from a **single unified project** at `src/Microsoft.Data.SqlClient/src/Microsoft.Data.SqlClient.csproj`, targeting `net462;net10.0` (minimum runtime compatibility: .NET Framework 4.6.2 and .NET 10). Public API declarations are unified under `src/Microsoft.Data.SqlClient/ref/`; reference and unsupported-platform projects additionally preserve `netstandard2.0`. The legacy `netfx/` and `netcore/` directories are no longer used.
 The project includes:
-- **Public APIs**: Defined in `netcore/ref/` and `netfx/ref/` directories.
+- **Public APIs**: Defined by `src/Microsoft.Data.SqlClient/ref/Microsoft.Data.SqlClient.csproj` and the reference source files beside it.
 - **Implementations**: All source code in `src/Microsoft.Data.SqlClient/src/`.
 - **Tests**: Located in the `tests/` directory, covering unit and integration tests.
   - **Unit Tests**: Located in `src/Microsoft.Data.SqlClient/tests/UnitTests/`.
@@ -51,12 +51,12 @@ This project includes several key products and libraries that facilitate SQL Ser
 - **Logging and Diagnostics**: Provides event source tracing diagnostic capabilities for troubleshooting.
 - **Failover Support**: Handles automatic failover scenarios for high availability.
   - Compatibility switch: `Switch.Microsoft.Data.SqlClient.UseLegacyFailoverAlternationOnLoginSqlErrors` (default `false`) can restore legacy alternation behavior in `LoginWithFailover` for login-phase SQL errors.
-- **Cross-Platform Support**: Compatible with both .NET Framework and .NET Core, allowing applications to run on Windows, Linux, and macOS.
+- **Cross-Platform Support**: Compatible with .NET Framework 4.6.2+ on Windows and .NET 10+ on Windows, Linux, and macOS.
 - **Column Encryption AKV Provider**: Supports Azure Key Vault (AKV) provider for acquiring keys from Azure Key Vault to be used for encryption and decryption.
 
 ## 🧩 SNI Implementations
 There are two implementations of the SQL Server Network Interface (SNI) layer used in this project:
-- **Managed SNI**: A managed implementation of SNI that is used in .NET Core and .NET 5+ environments. It provides cross-platform support for SQL Server connectivity.
+- **Managed SNI**: A managed implementation of SNI that is used in .NET 10+ environments. It provides cross-platform support for SQL Server connectivity.
 - **Native SNI**: A native implementation of SNI that is used in .NET Framework and .NET Core environments on Windows. It's shipped as part of the `Microsoft.Data.SqlClient.SNI` and `Microsoft.Data.SqlClient.SNI.Runtime` packages.
   - **Microsoft.Data.SqlClient.SNI**: This package provides the native SNI layer for .NET Framework applications.
   - **Microsoft.Data.SqlClient.SNI.Runtime**: This package provides the native SNI layer for .NET Core applications on Windows.
@@ -104,7 +104,22 @@ When a new issue is created, follow these steps:
 - Follow a test-driven approach: write failing tests before implementing fixes.
 - **Cover both sync and async code paths** where the API exposes both variants (e.g., `Open`/`OpenAsync`, `ExecuteReader`/`ExecuteReaderAsync`). Sync and async implementations often differ internally.
 - Use the existing test framework in the `tests/` directory.
-- Follow the naming conventions and structure of existing tests.
+- Read and follow the [test authoring rules](instructions/testing.instructions.md#writing-tests).
+  They are mandatory for unit tests and strongly recommended for manual and functional tests;
+  older neighboring tests do not override them.
+- Use commented Arrange, Act, Assert, Cleanup sections in order; Act and Assert are required.
+  Include Arrange only for needed setup and Cleanup only for special teardown. Comment each group
+  of steps within a section to explain what happens and, when unclear, why.
+- Use `[MemberData]` with a declared `TheoryData<...>` return type for non-constant theory data;
+  never use `[ClassData]` for it.
+- Keep `{ClassName}Tests.cs` focused on that class and mirror its source folder under `UnitTests/`.
+  Name tests `{MethodName}_{Input}_{ExpectedOutput}` without the tested class name.
+- Put unit-only utilities in `tests/UnitTests/Utilities/` and utilities shared across test projects
+  in TestCommon (`tests/Common/`), excluding fuzz, stress, and performance projects from this rule.
+- Split separate scenarios into separate tests; do not select behavior with switches or flags,
+  including sync/async switches. Use theories only to vary inputs for the same behavior.
+- Verify that tests exercise the intended behavior and assert outcomes that detect regressions.
+  Confirm the intended tests actually ran; skipped tests or zero matches do not establish coverage.
 - Ensure tests are comprehensive and cover edge cases.
 - If the issue involves changes to public APIs, update the corresponding `ref/` projects to reflect those changes.
 - Add sample code snippets in the 'doc/samples/' directory to demonstrate the new or fixed functionality and link them in the documentation in `doc/` folder.
@@ -132,12 +147,13 @@ When a new issue is created, follow these steps:
 - Tag reviewers based on `CODEOWNERS` file
 
 ## 🌿 Branch Naming
-- All branches created by AI agents **must** use the `dev/automation/` prefix (e.g. `dev/automation/fix-connection-timeout`).
-- Do **not** create branches directly under `main`, `dev/`, or any other top-level prefix.
+- **Interactive agents**, working under direct human guidance, may create and use branches under `dev/<name>/` when the human specifies or approves the namespace and branch name (e.g., `dev/paul/aot/phase-1.1`).
+- **Autonomous agents**, working without interactive human direction, **must** create branches under `dev/automation/` (e.g., `dev/automation/fix-connection-timeout`).
+- Do **not** create branches outside these namespaces or directly under `dev/`.
 
 ## 🧠 Contextual Awareness
 - All source code is in `src/Microsoft.Data.SqlClient/src/`. Do NOT add code to legacy `netfx/src/` or `netcore/src/` directories.
-- Only `ref/` folders in `netcore/ref/` and `netfx/ref/` remain active for defining the public API surface.
+- Public API changes must update the unified `src/Microsoft.Data.SqlClient/ref/` sources for each affected target framework.
 - Check for platform-specific differences using file suffixes (`.netfx.cs`, `.netcore.cs`, `.windows.cs`, `.unix.cs`) and conditional compilation (`#if NETFRAMEWORK`, `#if NET`, `#if _WINDOWS`, `#if _UNIX`).
 - Respect API compatibility rules across .NET versions
 - Do not introduce breaking changes without proper justification and documentation

.github/instructions/3rd-party-package-versions.instructions.md

@@ -3,12 +3,12 @@ applyTo: "**/Directory.Packages.props,**/*.csproj,**/Directory.Build.props,**/*.
 ---
 # Choosing Third-Party Package Dependency Versions
 
-Guidance for choosing versions of **external (third-party) NuGet package dependencies** in multi-targeted projects (e.g. `net462;net8.0;net9.0`).
+Guidance for choosing versions of **external (third-party) NuGet package dependencies** in multi-targeted projects (e.g. `net462;net10.0`).
 
 > **Scope:** This document covers dependencies consumed from NuGet — packages the SqlClient repo does NOT own. For versioning of SqlClient's own inter-sibling packages (Logging, Abstractions, SqlClient, Azure, AKV Provider, SqlServer.Server), see `sqlclient-package-versions.instructions.md`.
 
 ## Rule
-For runtime-aligned packages, **the package major must match the target runtime major**: 8.x on `net8.0`, 9.x on `net9.0`, 10.x on `net10.0`, and so on. TFMs that aren't tied to a specific runtime major (`net462`, `netstandard2.0`) get the major of the floor LTS. Other categories are versioned as described below.
+For runtime-aligned packages, **the package major must match the target runtime major**: 10.x on `net10.0` in this branch. TFMs that aren't tied to a specific runtime major (`net462`, `net481`, `netstandard2.0`) get the major of the floor LTS. Other categories are versioned as described below.
 
 Split package references into three categories:
 
@@ -22,21 +22,19 @@ Packages whose major version ships with (or is tightly coupled to) a specific .N
 - `System.Text.Json`, `System.Memory`, `System.IO.Pipelines`, `System.Formats.Asn1`, `System.Security.Cryptography.Pkcs`
 - `Microsoft.Bcl.*`
 
-Use the major version that matches the TFM. For TFMs without a corresponding runtime major (`net462`, `netstandard2.0`, etc.), use the major of the **lowest supported modern TFM** — typically the floor LTS (e.g. `8.x` while net8 is supported). This keeps the legacy targets on a long-lived, well-patched band and avoids dragging in transitive deps from a newer major:
+Use the major version that matches the TFM. For TFMs without a corresponding runtime major (`net462`, `net481`, `netstandard2.0`, etc.), use the major of the **lowest supported modern TFM** — currently .NET 10. This keeps the legacy targets on a long-lived, well-patched band and avoids dragging in transitive deps from a newer major:
 
 ```xml
-<!-- Defaults: lowest supported runtime band (e.g. net8 LTS); also applies to net462 / netstandard2.0 -->
+<!-- Defaults: .NET 10 LTS; also applies to net462 / net481 / netstandard2.0 -->
 <ItemGroup>
-  <PackageVersion Include="Microsoft.Extensions.Logging" Version="8.0.1" />
-  <PackageVersion Include="System.Text.Json"             Version="8.0.5" />
-</ItemGroup>
-
-<ItemGroup Condition="'$(TargetFramework)' == 'net9.0'">
-  <PackageVersion Update="Microsoft.Extensions.Logging" Version="9.0.0" />
-  <PackageVersion Update="System.Text.Json"             Version="9.0.0" />
+  <PackageVersion Include="Microsoft.Extensions.Logging" Version="10.0.0" />
+  <PackageVersion Include="System.Text.Json"             Version="10.0.0" />
 </ItemGroup>
 ```
 
+The versions above illustrate the runtime band; use the current stable servicing versions from
+`Directory.Packages.props`. No per-modern-TFM override is needed when only `net10.0` is targeted.
+
 When the floor LTS drops out of support, bump the default block to the new floor LTS major and drop any conditional block that becomes redundant.
 
 ### 2. Independent packages — **single version across all TFMs**
@@ -52,15 +50,15 @@ Reference one (latest stable) version unconditionally:
 
 ```xml
 <PackageVersion Include="Newtonsoft.Json" Version="13.0.4" />
-<PackageVersion Include="Azure.Identity"  Version="1.17.1" />
+<PackageVersion Include="Azure.Core"      Version="1.62.0" />
 ```
 
 ### 3. Polyfills — **conditional presence, single version**
 
 Packages that only exist (or are only needed) on older TFMs. The polyfill major doesn't have to match any runtime band (older TFMs have no in-box equivalent), so pick the latest stable available:
 
 ```xml
-<ItemGroup Condition="'$(TargetFramework)' == 'netstandard2.0' OR '$(TargetFramework)' == 'net462'">
+<ItemGroup Condition="'$(TargetFramework)' == 'netstandard2.0' OR '$(TargetFramework)' == 'net462' OR '$(TargetFramework)' == 'net481'">
   <PackageReference Include="Microsoft.Bcl.AsyncInterfaces" Version="10.0.0" />
 </ItemGroup>
 ```
@@ -96,7 +94,7 @@ Look at the "Frameworks" tab on nuget.org or open the `.nupkg`:
 
 ### 4. Functional test — remove the reference and rebuild
 
-The decisive test for the polyfill-vs-runtime-aligned boundary: remove the `PackageReference` on a modern TFM (e.g. net8) and build.
+The decisive test for the polyfill-vs-runtime-aligned boundary: remove the `PackageReference` on the modern TFM (`net10.0`) and build.
 
 - Builds clean → package was acting as a polyfill on that TFM. Confirm category 3.
 - Fails with `CS0246`/`CS1061` (missing type or method) → the package contributes API the in-box BCL doesn't have. Treat as runtime-aligned (category 1), even if the description sounds polyfill-ish.
@@ -143,13 +141,13 @@ The reverse (customer's direct version higher than your transitive) resolves cle
 | 10.x | 10.x or higher | Clean |
 | 8.x  | 8.x or higher | Clean |
 
-Pinning runtime-aligned packages to the **band matching each TFM** means a net8 consumer transitively gets 8.x (no friction with their own 8.x reference), and a net10 consumer transitively gets 10.x.
+For libraries supporting multiple modern runtimes, pinning runtime-aligned packages to the **band matching each TFM** means, for example, a net8 consumer transitively gets 8.x (no friction with their own 8.x reference), and a net10 consumer transitively gets 10.x.
 
-Pinning everything to the latest major (e.g. `10.x` unconditionally) forces every net8 customer to roll their direct references forward or hit NU1605.
+In that example, pinning everything to the latest major (e.g. `10.x` unconditionally) forces every net8 customer to roll their direct references forward or hit NU1605. This branch no longer targets net8; its only modern band is `net10.0`, so the current default is 10.x.
 
 ### Independent packages don't have this problem
 
-`Newtonsoft.Json 13.x`, `Azure.Identity 1.17.x`, etc. aren't tied to a runtime version. Customers don't have a "matching" version in mind, and the package's own multi-targeted assets handle TFM selection internally. One version is simpler and avoids needless conditional blocks.
+`Newtonsoft.Json 13.x`, `Azure.Core 1.62.x`, etc. aren't tied to a runtime version. Customers don't have a "matching" version in mind, and the package's own multi-targeted assets handle TFM selection internally. One version is simpler and avoids needless conditional blocks.
 
 ### Framework-provided assemblies win at runtime anyway