diff --git a/README.md b/README.md index 5b8a7f60..59d3e359 100644 --- a/README.md +++ b/README.md @@ -5,3 +5,7 @@ An implementation of `IAsyncEnumerable<'T>` as a computation expression: `taskSe ## Documentation See https://fsprojects.github.io/FSharp.Control.TaskSeq/ + +## Known issues + +- **Debug-mode truncation with recent .NET SDKs (SDK `10.0.400`+ / F# 10+)**: a `taskSeq { }` sequence that awaits (`do!`, `let!`, `Task.Delay`, etc.) between `yield`s can silently stop early when the *consuming* project is built in **Debug** configuration — `MoveNextAsync` returns `false` after the first await, with no exception or warning. **Release** builds (`-c Release` / `-p:Optimize=true`) are unaffected. This is not a bug in FSharp.Control.TaskSeq: it is an upstream F# compiler regression in Debug-mode state machine lowering for composed `ResumableCode` builders like this library's, tracked as [dotnet/fsharp#20466](https://github.com/dotnet/fsharp/issues/20466) with a fix in progress at [dotnet/fsharp#20469](https://github.com/dotnet/fsharp/pull/20469). If you observe unexpectedly short `taskSeq` sequences (for example in `dotnet test`, which defaults to Debug), try building/running in Release as a workaround; see #473 for details. diff --git a/release-notes.txt b/release-notes.txt index f0f7386b..ec2867ca 100644 --- a/release-notes.txt +++ b/release-notes.txt @@ -2,6 +2,7 @@ Release notes: Unreleased + - docs: add README "Known issues" section documenting an upstream F# compiler Debug-mode state machine lowering regression (dotnet/fsharp#20466, fix in progress at dotnet/fsharp#20469) that can silently truncate `taskSeq` sequences with awaits between yields in Debug builds; see #473 - tests: add coverage for side-effect re-execution semantics when re-enumerating a `taskSeq` with independent `CancellationToken`s - test: add TaskSeq.Issue452.Tests.fs, regression tests wrapping an externally-produced IAsyncEnumerable<'T> (TaskSeq.map and `taskSeq { for .. in .. do yield .. }`) while running on a custom, single-threaded TaskScheduler; investigates #452's reported duplicated-final-item bug, which could not be reproduced outside of Orleans, see #452 - adds TaskSeq.tryMax and TaskSeq.tryMin: safe variants of TaskSeq.max and TaskSeq.min that return None instead of raising ArgumentException when the input sequence is empty