Async.StartWithContinuations executing different continuation on .NET Core

[ncave]

When running Async.StartWithContinuations on a cancelled task, we can observe different behavior between net46 and netcoreapp1.0 targets:

• net46 goes to the cancellation handler (correct)
• netcoreapp1.0 goes to the exception handler (incorrect)

Sample code:

    open System

    let testAsyncContinuations =
        let res = ref "start"
        let tcs = new System.Threading.CancellationTokenSource()
        let work =
            let work = async {
                do! Async.Sleep 100
                res := "end"
            }
            tcs.Cancel false
            Task.Async.StartAsTask(work, cancellationToken=tcs.Token) |> Async.AwaitTask

        Async.StartWithContinuations(work,    // if work is a cancelled task
            (fun _ -> res := "continuation"),
            (fun _ -> res := "exception"),    // <-- netcoreapp1.0 goes here (incorrect)
            (fun _ -> res := "cancellation")) // <-- net46 goes here (correct)

        Async.Sleep 200 |> Async.RunSynchronously
        res

    [<EntryPoint>]
    let main argv =
        printf "==> %A" testAsyncContinuations
        0

[eiriktsarpalis]

@ncave you're probably seeing this because of the changes introduced by #1166, #1191. In short, binding on cancelled tasks should not trigger the cancellation continuation, but rather force a catchable TaskCancelledException. The cancellation continuation is reserved for cooperative cancellation by the async workflow only.

[eiriktsarpalis]

@ncave which means that the behavior will also be changing as of F# 4.1 in net46

[ncave]

@eiriktsarpalis Thank you for your explanation, it was very helpful.

I probably don't have a good grasp on the design behind the Async API, but isn't your PR #1191 kind of invalidating the whole purpose of having a cancellation continuation, if we'll have to check for System.OperationCanceledException in the exception continuation anyway, even when the task was explicitly cancelled with a cancellation token without throwing an exception?

I get that some tasks may be cancelled on timeout when they actually should be throwing exceptions, but isn't that a problem with the task's implementation that needs to be addressed there? If not, if the expected behavior is to always throw on cancellation, then maybe we don't need the cancellation continuation? It will just confuse the user, who will expect the cancellation continuation to run on a cancelled task, which it will not.

(just trying to understand the design better, thank you for your help)

[eiriktsarpalis]

No, the intended purpose of the cancellation continuation is to provide a means for workflow cancellation:

let cts = new CancellationTokenSource()
Async.StartAsTask(asyncWorkflow, cancellationToken = cts.Token)
cts.Cancel()

It should only be fired in the event of the externally supplied cancellation token being cancelled. In F# <= 4.0 the Async.AwaitTask implementation was erroneously triggering the cancellation continuation whenever the task got cancelled, meaning that it would be impossible to exception handle in the async context.

[ncave]

Do you mean the intended purpose of cancellation token source, or cancellation continuation? My question was about the purpose of the cancellation continuation, if (now) cancelling the token would always trigger the exception continuation.

To be more specific, I'm referring to the perceived inconsistency in Async.StartWithContinuations:

• if you start with a task that gets cancelled, it calls the exception continuation, not the cancellation continuation.
• if you start with a task and supply the (optional) token source parameter that you cancel afterwards, it calls the cancellation continuation. But it's an optional parameter, so if the user omits it she may have the wrong expectations about which continuation will be executed.

If this is how it should be, maybe it just needs to be documented better, but it does seem a bit counter-intuitive.

[eiriktsarpalis]

I'm referring to the cancellation continuation. Also, this is unrelated to Async.StartWithContinuations. The observed behavior really reflects the implementation of Async.AwaitTask. Please see #1166 for a minimal example that illustrates the introduced change.

[ncave]

I did not realize ccont also raises exception, then it's kind of the same. But then continueWithUnit needs to be fixed the same way, right?

The change does alter the expected behavior downstream (e.g. Async.StartWithContinuations, see above), so it would be nice if that can be fixed somehow (so the correct continuation is called by Async.StartWithContinuations), or at least the new behavior needs to be well documented.

[eiriktsarpalis]

I might raise an exception eventually, but the two are fundamentally different by the fact that the cancellation cont cannot be caught by exception handlers.

That's a good observation actually, continueWithUnit needs to be changed as well. We currently have inconsistent behavior. @dsyme @KevinRansom This probably needs to be fixed for F# 4.1. I'll create a PR

[dsyme]

@eiriktsarpalis @ncave Can we close this?

[eiriktsarpalis]

I think we can, this is expected behaviour

…

On Thu, 24 Nov 2016 at 18:47, Don Syme ***@***.***> wrote: @eiriktsarpalis <https://github.com/eiriktsarpalis> @ncave <https://github.com/ncave> Can we close this? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1416 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACrts_vFEUb5RnOyUPWOAQptUS4Fh4X8ks5rBdvHgaJpZM4Jhnl0> .

[ncave]

Yes, although it's still a bit unexpected behavior from user's point of view. Closing.