NullReferenceException in SqlConnection.UseLocally

[daniellittledev]

Issue Summary

I've run into a NullReferenceException internal to FSharp.Data.SqlClient.

To Reproduce

I'm not exactly sure of how to reproduce it but it's possibly caused by a timeout or database error.

Error

System.NullReferenceException: Object reference not set to an instance of an object. at
FSharp.Data.SqlClient.Internals.Extensions.SqlConnection.UseLocally(SqlConnection this, FSharpOption`1 privateConnection) at
<StartupCode$FSharp-Data-SqlClient>.$ISqlCommand.AsyncExecuteNonQuery@374.Invoke(Unit unitVar) at
Microsoft.FSharp.Control.AsyncPrimitives.CallThenInvoke[T,TResult](AsyncActivation`1 ctxt, TResult result1, FSharpFunc`2 part2) in D:\a\_work\1\s\src\FSharp.Core\async.fs:line 508

Expected behavior

I would expect to see a database error, not a null reference inside FSharp.Data.SqlClient.

What you can do

• [] I am willing to contribute a PR with a unit test showcasing the issue
• I am willing to test the bug fix before next release

[smoothdeveloper]

@daniellittledev, thanks for the report, with the stacktrace, we know the issue surfaced from this:

FSharp.Data.SqlClient/src/SqlClient/ISqlCommand.fs

Line 374 in 712b8cb

use _ = cmd.Connection.UseLocally(manageConnection )

Can you update us with your intuition if this is a case of SQL Server dropping a connection due to activity there?

I am not aware on the issues that came in terms of implementing the async support, but the implementation of the UseLocally doesn't strike as NRE triggering type of code, I'd assume with a full debug build, the stacktrace may highlight SqlConnection object.

I don't have the context on the UseLocally function, but it basically ensures in different contexts, that code wouldn't leave open connections if the code path is one where the library will manage the connection.

Are you creating the commands using a connection string or connection, transaction timeouts constructor?

You can see here:

FSharp.Data.SqlClient/src/SqlClient/ISqlCommand.fs

Line 57 in 712b8cb

let manageConnection =

and try to identify if in your context, how this would flow, down to

FSharp.Data.SqlClient/src/SqlClient/ISqlCommand.fs

Line 105 in 712b8cb

``ISqlCommand Implementation``.AsyncExecuteNonQuery manageConnection >> box,

I would suggest not using connection string constructor for production code, always have your top level code handling the overall workflow manage the connections.

Design wise, I'd consider removing the code that deals with connection string only constructors, I think this has been discussed a bit back & forth, but even in scripting context, it is bad practice (you surrender ability for code to be handled in a transaction, or just deal with basic command timeout setup).

I would on the other hand, provide a constructor parameter of type unit -> IDbCommand or unit -> SqlCommand that would also replace how currently, you have to pass 3 things to do it properly (which can be worked around with SRTP, thankfully).

Sorry for not having seen this earlier, and please feel free to come back with more insights about what may be occurring in your case.

[github-actions]

🤖 This is an automated response from Repo Assist.

Thanks for the report. After tracing through the code I can explain what's likely happening.

Root cause: cmd.Connection null after async timeout/error

The NRE occurs in AsyncExecuteNonQuery at this line in ISqlCommand.fs:

static member internal AsyncExecuteNonQuery manageConnection (cmd, _, parameters, _) = 
    ``ISqlCommand Implementation``.SetParameters(cmd, parameters)  
    async {         
        use _ = cmd.Connection.UseLocally(manageConnection)  // ← NRE here
        return! cmd.AsyncExecuteNonQuery() 
    }

UseLocally is an F# extension method on SqlConnection; if cmd.Connection is null, accessing this.State inside UseLocally throws the NRE.

When can cmd.Connection be null? The most common scenario is the Choice3Of3 tran (transaction) constructor path:

| Choice3Of3 tran -> 
    let cmd = tran.Connection.CreateCommand(Transaction = tran)
    false, cmd

After a SqlTransaction is committed or rolled back, ADO.NET sets SqlTransaction.Connection to null. If the same ISqlCommand Implementation object is then reused — or if the transaction completes concurrently with an in-flight async operation — cmd.Connection can end up null by the time the async continuation executes.

A secondary scenario: if the SqlConnection object passed via Choice2Of3 is disposed or broken due to a network timeout while an async operation is queued on the thread pool, the cmd.Connection reference can be cleared by the ADO.NET internal state machine.

Workaround

Create a new command instance for each call after a transaction completes, or ensure the connection/transaction remains valid for the lifetime of all outstanding async operations on the command.

Potential fix

Add a null guard before calling UseLocally:

async {         
    if not (isNull cmd.Connection) then
        use _ = cmd.Connection.UseLocally(manageConnection)
        return! cmd.AsyncExecuteNonQuery() 
    else
        return! cmd.AsyncExecuteNonQuery()
}

or equivalently, add a null guard inside UseLocally itself. A more robust fix would propagate a descriptive InvalidOperationException with guidance rather than letting a NullReferenceException escape.

Generated by Repo Assist · ◷

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/repo-assist.md@346204513ecfa08b81566450d7d599556807389f