Summary
TaskSeq.map and taskSeq { for item in upstream do yield ... } over an externally produced IAsyncEnumerable<T> each yield the final item twice when the consumption runs on a non-default TaskScheduler — observed deterministically inside a Microsoft Orleans grain activation (Orleans' per-activation scheduler). Enumerating the same IAsyncEnumerable<T> directly (the exact await foreach desugaring: GetAsyncEnumerator / MoveNextAsync / Current / DisposeAsync) yields the correct count.
Environment
FSharp.Control.TaskSeq 0.6.0- .NET 10 (
net10.0), F#
- Reproduces identically on Microsoft Orleans 10.1.0 and 10.2.2 (the enumerable being wrapped is produced by Orleans'
IAsyncEnumerableGrainExtension machinery — batched MoveNext pulls over grain calls)
The discriminator (what isolates it to the wrapping construct)
One grain method consumes the same 3-item upstream stream three ways and returns the three counts as an ordinary unary reply, so nothing about our own streaming-reply transport participates in the measurement:
let! direct = TaskSeq.toListAsync (upstream.watch (label, 3)) // plain enumeration of the source
let! viaMap =
upstream.watch (label2, 3)
|> TaskSeq.map (fun tick -> tick.note) // wrapped
|> TaskSeq.toListAsync
let! viaFor =
TaskSeq.toListAsync (taskSeq { // wrapped
for tick in upstream.watch (label3, 3) do yield tick.note
})Result, measured 2026-08-18, stable across runs and across both Orleans versions:
(List.length direct, List.length viaMap, List.length viaFor) = (3, 4, 4)
direct = 3 is correct; both wrapping forms report 4 items for a 3-item stream, the last item duplicated.
What tracing showed
Instrumenting all enumerator layers on the failing path localized it precisely: the taskSeq wrapper yielded one extra MoveNextAsync = true with a stale Current immediately after the inner enumerator had already answered false.
What we ruled out
- Our own enumerable implementation:
direct enumeration is correct everywhere, including batched sources, empty sources, and a throwing producer.
- The obvious structural suspects: four progressively more faithful offline models on the ordinary thread pool — an all-synchronous enumerator, a batched one, one whose terminating
MoveNextAsync completes asynchronously, and a full in-process re-implementation of the Orleans pull loop driving two stacked legs — none reproduced it. The trigger appears to require the custom TaskScheduler an Orleans activation runs on.
Repro status (honest)
We could not reduce it to a standalone console repro — that is the main obstacle to a better report, and why this issue points at a live test instead. In our repository it reproduces deterministically:
To observe the raw counts: clone the branch, change the discriminator's assertion to print the tuple, and run dotnet test tests/Orleans.FSharp.Integration --filter "FullyQualifiedName~consuming an upstream stream inside a grain".
Happy to run any diagnostic build or instrumented package against this environment if that helps narrow it down.
Summary
TaskSeq.mapandtaskSeq { for item in upstream do yield ... }over an externally producedIAsyncEnumerable<T>each yield the final item twice when the consumption runs on a non-defaultTaskScheduler— observed deterministically inside a Microsoft Orleans grain activation (Orleans' per-activation scheduler). Enumerating the sameIAsyncEnumerable<T>directly (the exactawait foreachdesugaring:GetAsyncEnumerator/MoveNextAsync/Current/DisposeAsync) yields the correct count.Environment
FSharp.Control.TaskSeq0.6.0net10.0), F#IAsyncEnumerableGrainExtensionmachinery — batchedMoveNextpulls over grain calls)The discriminator (what isolates it to the wrapping construct)
One grain method consumes the same 3-item upstream stream three ways and returns the three counts as an ordinary unary reply, so nothing about our own streaming-reply transport participates in the measurement:
Result, measured 2026-08-18, stable across runs and across both Orleans versions:
direct = 3is correct; both wrapping forms report 4 items for a 3-item stream, the last item duplicated.What tracing showed
Instrumenting all enumerator layers on the failing path localized it precisely: the
taskSeqwrapper yielded one extraMoveNextAsync = truewith a staleCurrentimmediately after the inner enumerator had already answeredfalse.What we ruled out
directenumeration is correct everywhere, including batched sources, empty sources, and a throwing producer.MoveNextAsynccompletes asynchronously, and a full in-process re-implementation of the Orleans pull loop driving two stacked legs — none reproduced it. The trigger appears to require the customTaskScheduleran Orleans activation runs on.Repro status (honest)
We could not reduce it to a standalone console repro — that is the main obstacle to a better report, and why this issue points at a live test instead. In our repository it reproduces deterministically:
direct = 3; deliberately does not pin the divergent value so an upstream fix cannot break our suite): https://github.com/Neftedollar/orleans-fsharp/blob/e31b2e3c5190acb1cbcaadd4078dccd8d67b6b95/tests/Orleans.FSharp.Integration/FunctionalPhaseFIntegrationTests.fs#L598-L627To observe the raw counts: clone the branch, change the discriminator's assertion to print the tuple, and run
dotnet test tests/Orleans.FSharp.Integration --filter "FullyQualifiedName~consuming an upstream stream inside a grain".Happy to run any diagnostic build or instrumented package against this environment if that helps narrow it down.