Why does this IDisposable get disposed while referenced in a F# task? - .net-core

Question

A while ago, in one of our (X)unit tests, a colleague of mine wrote:
[<Fact>]
let ``Green Flow tests`` () =
use factory = new WebAppFactory()
use client = factory.CreateClient()
Check.theGreenFlow client
|> Async.AwaitTask
|> Async.RunSynchronously
Surprised, I was wondering why my colleague forced a call to Async.RunSynchronously while XUnit works fine with Task and Async types alike.
I then tried out:
[<Fact>]
let ``Green Flow tests`` () =
use factory = new WebAppFactory()
use client = factory.CreateClient()
// this btw returns Task<unit>
Check.theGreenFlow client
And got:
Rm.Bai.IntegrationTests.RetrievalWorkflow.Green Flow tests
System.AggregateException : One or more errors occurred. (One or more errors occurred. (One or more errors occurred. (One or more errors occurred. (One or more errors occurred. (One or more errors occurred. (Cannot access a disposed object.
Object name: 'IServiceProvider'.))))))
I was like "ok fair enough, scope of use ends at the bottom of the function, then released while the Task<unit> is processed by the XUnit runner".
Even though the IDisposable objects might be referenced in a function returning a Task in the example above, the runner runs the task after the end of the function and so the Dispose call has already occurred according to my understanding of https://learn.microsoft.com/en-us/dotnet/fsharp/language-reference/resource-management-the-use-keyword:
It provides the same functionality as a let binding but adds a call to Dispose on the value when the value goes out of scope. Note that the compiler inserts a null check on the value, so that if the value is null, the call to Dispose is not attempted.
[...]
when you use the use keyword, Dispose is called at the end of the containing code block
To me, the right way to avoid disposed object would have been to wrap in a computation expression like task or async computation expression:
[<Fact>]
let ``Green Flow tests`` () =
task {
use factory = new WebAppFactory()
use client = factory.CreateClient()
do! Check.theGreenFlow client
}
So that the moment when Dispose() is actually code is clearly defined.
And don't necessarily force the test to be run synchronously like in the snippet no. 1.
Unlike something like below, which still would lead to a Cannot access a disposed object. error:
[<Fact>]
let ``Green Flow tests`` () =
use factory = new WebAppFactory()
use client = factory.CreateClient()
async {
do! Check.theGreenFlow client |> Async.AwaitTask
}
Which is akin the snippet no. 2.
Is my understanding of this issue correct?

Answer 1

Next experiment demonstrates the flow of your second example (when there is Check.theGreenFlow client at the end). F#:
let tst(runSvc:Func<_,_>) =
printfn "[%d] start tst" Thread.CurrentThread.ManagedThreadId
use srv = {new IDisposable with
override x.Dispose() =
printfn "[%d] srv disposed" Thread.CurrentThread.ManagedThreadId }
let res: Task = runSvc.Invoke srv
printfn "[%d] end tst" Thread.CurrentThread.ManagedThreadId
res
this is analog of Green Flow tests. C#:
static async Task runSvc(IDisposable svc) {
Console.WriteLine($"[{Thread.CurrentThread.ManagedThreadId}] before runSvc");
await Task.Delay(1000);
Console.WriteLine($"[{Thread.CurrentThread.ManagedThreadId}] after runSvc");
}
static async Task Main(string[] args)
{
var task = T1.tst(runSvc);
await task;
}
runSvc plays role of Check.theGreenFlow and Main - role of XUnit test run.
The output:
[1] start tst
[1] before runSvc
[1] end tst
[1] srv disposed
[4] after runSvc
First thread starts the test and goes into Check.theGreenFlow.
At some point Check.theGreenFlow registers a continuation for asynchronous operation - in this example it is at point task.Delay.
After continuation registration, Check.theGreenFlow immediately returns with object Task (in my example, continuation is printing "after runSvc" and this part is registered for later).
When code returns from test function, service objects are disposed at the end and thread 1 awaits for result, which at some point will be created by registered continuation in the threadpool (another thread 4 executes "after runSvc"). If thread 4 accesses service objects in continuation, object disposed exception happens.
There could be race conditions. If in my example above you put Thread.Sleep(2000) before "[%d] end tst", continuation "after runSvc" will execute before disposal and there is no exception.