Task to AsyncResult transition wraps `Exception` into the `AggregateException`

[xperiandri]

Task to AsyncResult transition wraps `Exception` into the `AggregateException`

[xperiandri]

As long as it is a FSharp.Core issue I propose to use a corrected way of awaiting tasks
https://github.com/jet/FsKafka/blob/6c6186f822a221adf0ad06e8a44a392aa55aa8ec/src/FsKafka/Infrastructure.fs#L14 instead of Async.AwaitTask

[TheAngryByrd]

Hey @NinoFloris see any downsides to doing this?

[TheAngryByrd]

I don't think this is a problem with FsToolkit as this is how exceptions are thrown with Tasks via .NET https://docs.microsoft.com/en-us/dotnet/standard/parallel-programming/exception-handling-task-parallel-library

[xperiandri]

Is it how async CE works itself?

[xperiandri]

It does not happen with await in C#

[xperiandri]

Ah, this is the issue fsharp/fslang-suggestions#840

[njlr]

I have this helper in various code-bases:

let rec unpackException (exn : Exception) = 
  match exn with
  | :? AggregateException as agg -> 
    match Seq.tryExactlyOne agg.InnerExceptions with
    | Some x -> unpackException x
    | None -> exn
  | _ -> exn

[bartelink]

As long as it is a FSharp.Core issue I propose to use a corrected way of awaiting tasks https://github.com/jet/FsKafka/blob/6c6186f822a221adf0ad06e8a44a392aa55aa8ec/src/FsKafka/Infrastructure.fs#L14 instead of Async.AwaitTask

Note the edition therein in being synced with the canonical one in jet/FsKafka#92 (similarly fsprojects/FSharp.AWS.DynamoDB#49)

The key specific diff in there is that cancellation will be guaranteed yield an exception, but the more important effect is that people debugging systems can do that based on being able to assume-but-verify identical behavior vs the needless variation having slight variations can cause (especially if we do manage to converge in the end).