Support withCancellation

[xperiandri]

When you call .WithCancellation(cancellationToken) on IAsyncEnumerable<'T> you get System.Runtime.CompilerServices. ConfiguredCancelableAsyncEnumerable<'T> which is not currently supported.

So that this code does not work

    static member ToFlatListAsync<'Source>(source: IQueryable<'Source>, [<Optional>] cancellationToken: CancellationToken) = task {
        let builder = ImmutableArray.CreateBuilder<'Source>()
        do!
            source.AsAsyncEnumerable().WithCancellation(cancellationToken)
            |> TaskSeq.iterAsync (fun x -> builder.Add(x))

        return builder.ToImmutable();
    }

[abelbraaksma]

This is actually very interesting. Reading up on the design decisions for WithCancellation, as Don Syme and myself were about creating our own solution, but it is, obviously, better to use dotnet's own methods, if they are applicable.

Just checked, this method is part of NetStandard 2.1, so I can actually add it. Another method in those extensions that is very interesting is ToBlockingEnumerable. This is a .NET 7+ extension, but I might take its code for the blocking operations I have, to ensure similar behavior.

[abelbraaksma]

Related discussion: #133

[abelbraaksma]

This turns out to be much harder to support than I thought. But one of the soon-to-be-made changes is going to be a move to static methods, so we can support adding a cancellation token in each call immediately, removing the need for calling WithCancellation, but that means threading an overload through the whole system.

To support this, we either need to overload every single method such that it accepts that type, or we have to go SRTP (and/or with an SRTP overload).

Instead, I may consider something like ofWithCancellation (ugly method name, I know), which would itself return an IAsyncEnumerable but with a collected cancellation token. This is, however, not ideal, as the token should be given to GetEnumerator(token). Hmm, I'll think a bit more about this.

The reason this is non-trivial is because ConfiguredCancelableAsyncEnumerable<T> is a struct and does not implement any useful interface. I'm also a little confused as to why MS chose to internally effectively call ConfigureAwait(true), which, from library code, is considered bad practice in general (and can lead to deadlocks).

[xperiandri]

Maybe raise an issues on .NET repo about the use of ConfiguredCancelableAsyncEnumerable<T>?

[abelbraaksma]

That likely wouldn't help. It is a struct for a reason. While it keeps a reference to the IAsyncEnumerable<_> internally, it makes the overhead of making your enumerable cancelable really small. There's no need for a newobj IL instruction.

[github-actions]

🤖 This is an automated response from Repo Assist.

Commenting to share a practical workaround and clarify the technical limitation.

Why it's hard

ConfiguredCancelableAsyncEnumerable(T) is a struct that does not implement IAsyncEnumerable(T). Its GetAsyncEnumerator() returns a ConfiguredCancelableAsyncEnumerator(T) (another struct), whose MoveNextAsync() returns ConfiguredValueTaskAwaitable(bool) rather than ValueTask(bool). This means the taskSeq builder's WhileAsync path (which expects unit -> ValueTask(bool)) cannot consume it directly.

Practical workaround (no library changes needed)

Until a dedicated helper exists, you can write a small local adapter using IAsyncEnumerator(T) directly:

/// Wraps an IAsyncEnumerable with an explicit CancellationToken into a TaskSeq.
let inline withCancellation (ct: CancellationToken) (source: IAsyncEnumerable<'T>) : TaskSeq<'T> =
    taskSeq {
        use e = source.GetAsyncEnumerator(ct)
        while! e.MoveNextAsync() do
            yield e.Current
    }

// Usage (replaces .WithCancellation(cancellationToken)):
source.AsAsyncEnumerable()
|> withCancellation cancellationToken
|> TaskSeq.iterAsync (fun x -> builder.Add(x))

This calls GetAsyncEnumerator(ct) on the underlying IAsyncEnumerable(T) with the explicit token, which EF Core (and other providers) will honour correctly for cooperative cancellation.

Potential library addition

A TaskSeq.withCancellation : CancellationToken -> TaskSeq<'T> -> TaskSeq<'T> (or equivalently a static method) wrapping the pattern above would be a clean, low-complexity addition that directly addresses this issue, without needing to touch ConfiguredCancelableAsyncEnumerable(T) at all. The withCancellation helper above is essentially what such a function would look like internally.

Generated by Repo Assist · ◷

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/repo-assist.md@5029c9574c7bd2baa70aab6c8de9ea09edf11803

[dsyme]

/repo-assist Add this withCancellation in a PR

[github-actions]

Pull request created: #339

Generated by Repo Assist

[github-actions]

🤖 Repo Assist here — following @dsyme's request, I've implemented TaskSeq.withCancellation and opened a draft PR.

The implementation is a lightweight wrapper that passes the supplied CancellationToken directly to GetAsyncEnumerator, mirroring .WithCancellation() semantics without requiring any interaction with ConfiguredCancelableAsyncEnumerable(T):

// Usage — replaces .WithCancellation(cancellationToken):
source.AsAsyncEnumerable()
|> TaskSeq.withCancellation cancellationToken
|> TaskSeq.iterAsync (fun x -> builder.Add(x))

The PR includes:

• TaskSeq.withCancellation : CancellationToken -> TaskSeq<'T> -> TaskSeq<'T> in the public API
• 10 tests covering null-check, token threading, pre/mid-iteration cancellation, and combinator composition
• All 4711 existing tests still pass

Generated by Repo Assist for issue #167 · ◷

To install this agentic workflow, run

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