SqlCommand.Cancel throws NullReferenceException when Connection is null

[smophat7]

Describe the bug

After transitioning from v6.1.5 to v7.0.0, SqlCommand.Cancel now throws a NullReferenceException if SqlCommand.Connection is null.

Exception:

System.NullReferenceException: Object reference not set to an instance of an object.
   at Microsoft.Data.SqlClient.SqlCommand.Cancel()
   at Program.<Main>$(String[] args) in /<path-to-project>/Program.cs:line 6

The line that causes the exception is a log statement near the beginning of the Cancel method. This PR included a change from Connection?.ClientConnectionId (source) to _activeConnection.ClientConnectionId (source), omitting the null-conditional operator, which was correctly retained in the Clone method's analogous log statement.

To reproduce

See this repo for a complete reproduction of the issue.

In summary, this following code behaves differently when using v7.0.0 compared to v6.1.5:

using Microsoft.Data.SqlClient;

SqlCommand command = new();
try
{
    command.Cancel();
    Console.WriteLine("Success!");
}
catch (Exception e)
{
    Console.WriteLine(e);
}

Expected behavior

Expected in v7.0.0: SqlCommand.Cancel() does not throw and is essentially a no-op
Actual in v7.0.0: SqlCommand.Cancel() throws a NullReferenceException.

Further technical details

Microsoft.Data.SqlClient version: v7.0.0
.NET target: .NET 10.0
SQL Server version: N/A
Operating system: Fedora Linux 44 (KDE Plasma Desktop Edition) - Linux version 7.0.6-200.fc44.x86_64

Additional context
The incorrect behavior is confirmed to still be present in v7.1.0-preview1.26124.5 (latest at time of writing).

[github-actions]

🔍 Triage Summary

Check	Result
Issue type	Bug
Environment	All required environment details provided for investigation
Area	Area\Engineering (SqlCommand core behavior)
Duplicates	None found
Regression	Likely regression from v6.1.5 → v7.0.0 introduced by PR #3655

Analysis

SqlCommand.Cancel() throws a NullReferenceException when Connection is null (i.e., the command was never associated with a connection). The root cause has been precisely identified by the reporter: PR #3655 changed a null-conditional access Connection?.ClientConnectionId to _activeConnection.ClientConnectionId in the logging statement at the top of the Cancel method, dropping the null guard. The same null-conditional was correctly preserved in the Clone method's analogous log statement. This is a straightforward P1 regression — Cancel() on an unassociated command was a documented no-op prior to v7.0.0 and the fix is a one-line change. The issue is confirmed to also affect v7.1.0-preview1.

Next Steps

• Assign to Copilot coding agent to fix SqlCommand.Cancel() in src/Microsoft.Data.SqlClient/src/ — restore the null-conditional operator on _activeConnection in the log statement (change _activeConnection.ClientConnectionId back to _activeConnection?.ClientConnectionId).
• Add a unit test covering SqlCommand.Cancel() with a null Connection to prevent future regressions.
• Verify the fix covers any other locations in Cancel() that may dereference _activeConnection without a null check.

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 issue #4327 · ● 1.6M · ◷