Can endless async workflow overflow stack - asynchronous

Question

Suppose we have this potentially endless workflow:
let workAsync i = async {
printfn "Working... %A" i
if i > 3 then
failwith "errg"
elif i = -1000 then // ensure work is async
do! Async.Sleep 0
return i+1
}
let workflow =
async {
let mutable i = 0
while true do // I can't quit you!
let! j = workAsync i
i <- j
//do! Async.Sleep 0 // This is important?
} |> Async.RunSynchronously
If you run this, we get the expected exception. Notice how the stacktrace has grown. This can be made larger.
Working... 0
Working... 1
Working... 2
Working... 3
Working... 4
> System.Exception: errg
at FSI_0017.workAsync#155-45.Invoke(Unit unitVar) in C:\work\website_tq\tqit7\fs\Scripts\fsi_basic.fsx:line 157
at Microsoft.FSharp.Control.AsyncPrimitives.CallThenInvoke[T,TResult](AsyncActivation`1 ctxt, TResult result1, FSharpFunc`2 part2)
at Microsoft.FSharp.Control.AsyncPrimitives.unitAsync#607.Invoke(AsyncActivation`1 ctxt)
at FSI_0017.workAsync#158-47.Invoke(AsyncActivation`1 ctxt) in C:\work\website_tq\tqit7\fs\Scripts\fsi_basic.fsx:line 158
at Microsoft.FSharp.Control.AsyncPrimitives.unitAsync#607.Invoke(AsyncActivation`1 ctxt)
at Microsoft.FSharp.Control.AsyncPrimitives.unitAsync#607.Invoke(AsyncActivation`1 ctxt)
at FSI_0017.workAsync#158-47.Invoke(AsyncActivation`1 ctxt) in C:\work\website_tq\tqit7\fs\Scripts\fsi_basic.fsx:line 158
at Microsoft.FSharp.Control.AsyncPrimitives.unitAsync#607.Invoke(AsyncActivation`1 ctxt)
at Microsoft.FSharp.Control.AsyncPrimitives.unitAsync#607.Invoke(AsyncActivation`1 ctxt)
at FSI_0017.workAsync#158-47.Invoke(AsyncActivation`1 ctxt) in C:\work\website_tq\tqit7\fs\Scripts\fsi_basic.fsx:line 158
at Microsoft.FSharp.Control.AsyncPrimitives.unitAsync#607.Invoke(AsyncActivation`1 ctxt)
at Microsoft.FSharp.Control.AsyncPrimitives.unitAsync#607.Invoke(AsyncActivation`1 ctxt)
at FSI_0017.workAsync#158-47.Invoke(AsyncActivation`1 ctxt) in C:\work\website_tq\tqit7\fs\Scripts\fsi_basic.fsx:line 158
at Microsoft.FSharp.Control.AsyncPrimitives.unitAsync#607.Invoke(AsyncActivation`1 ctxt)
at Microsoft.FSharp.Control.Trampoline.Execute(FSharpFunc`2 firstAction)
--- End of stack trace from previous location where exception was thrown ---
at Microsoft.FSharp.Control.AsyncResult`1.Commit()
at Microsoft.FSharp.Control.AsyncPrimitives.RunSynchronouslyInAnotherThread[a](CancellationToken token, FSharpAsync`1 computation, FSharpOption`1 timeout)
at Microsoft.FSharp.Control.AsyncPrimitives.RunSynchronously[T](CancellationToken cancellationToken, FSharpAsync`1 computation, FSharpOption`1 timeout)
at Microsoft.FSharp.Control.FSharpAsync.RunSynchronously[T](FSharpAsync`1 computation, FSharpOption`1 timeout, FSharpOption`1 cancellationToken)
at <StartupCode$FSI_0017>.$FSI_0017.main#() in C:\work\website_tq\tqit7\fs\Scripts\fsi_basic.fsx:line 161
BUT if we uncomment the Async.Sleep line, the stack does not grow:
Working... 0
Working... 1
Working... 2
Working... 3
Working... 4
> System.Exception: errg
at FSI_0002.workAsync#155.Invoke(Unit unitVar) in C:\work\website_tq\tqit7\fs\Scripts\fsi_basic.fsx:line 157
at Microsoft.FSharp.Control.AsyncPrimitives.CallThenInvoke[T,TResult](AsyncActivation`1 ctxt, TResult result1, FSharpFunc`2 part2)
at FSI_0002.workflow#167-5.Invoke(AsyncActivation`1 ctxt) in C:\work\website_tq\tqit7\fs\Scripts\fsi_basic.fsx:line 167
at Microsoft.FSharp.Control.Trampoline.Execute(FSharpFunc`2 firstAction)
--- End of stack trace from previous location where exception was thrown ---
at Microsoft.FSharp.Control.AsyncResult`1.Commit()
at Microsoft.FSharp.Control.AsyncPrimitives.RunSynchronouslyInAnotherThread[a](CancellationToken token, FSharpAsync`1 computation, FSharpOption`1 timeout)
at Microsoft.FSharp.Control.AsyncPrimitives.RunSynchronously[T](CancellationToken cancellationToken, FSharpAsync`1 computation, FSharpOption`1 timeout)
at Microsoft.FSharp.Control.FSharpAsync.RunSynchronously[T](FSharpAsync`1 computation, FSharpOption`1 timeout, FSharpOption`1 cancellationToken)
at <StartupCode$FSI_0002>.$FSI_0002.main#() in C:\work\website_tq\tqit7\fs\Scripts\fsi_basic.fsx:line 161
* Modified: * Changed workAsync to ensure the async'nicity isn't optimized away.

Answer 1

This happens because there is nothing actually async in your workflow when Sleep is commented out.
Everything is completely synchronous, but because it's encoded in the async computation expression, it becomes weirdly nested. See, every let! line actually calls whatever is on the right side (in your example - workAsync) and passes it a callback that needs to be called once the asynchronous part is done. The callback contains the rest of the code - a continuation starting right after the let! line. The compiler performs clever transformations on the code to make it look all nice and linear, when in reality it's a series of callbacks.
However, since workAsync is not actually asynchronous, it just calls the callback right away, and the callback turns around and calls the next iteration of workAsync, and so on. And so your stack grows.
But wait! It actually shouldn't grow after all. Invocation of the callback is the last call in workAsync - also known as "tail call", - and both .NETCore and .NET Framework do eliminate those (and indeed: on my machine I cannot reproduce your result). The only speculation I can offer is that you must be running this on Mono, which doesn't always eliminate tail calls.
If you uncomment Sleep, however, then it becomes the breaking point. Sleep is actually asynchronous, which means that it schedules the callback to be executed on a new thread after a timeout. That execution starts from scratch, with a fresh stack, and so the stack doesn't grow, even when tail calls are not eliminated.
So to answer your original question: no, an endless async computation cannot overflow stack, except when it's not actually async and runs on Mono.