Skip to content

[Repo Assist] test: add SideEffects module to TaskSeq.OfXXX.Tests.fs#407

Draft
github-actions[bot] wants to merge 2 commits intomainfrom
repo-assist/test-ofxxx-sideeffects-20260424-c044cc685e66a474
Draft

[Repo Assist] test: add SideEffects module to TaskSeq.OfXXX.Tests.fs#407
github-actions[bot] wants to merge 2 commits intomainfrom
repo-assist/test-ofxxx-sideeffects-20260424-c044cc685e66a474

Conversation

@github-actions
Copy link
Copy Markdown
Contributor

🤖 This is an automated pull request from Repo Assist, an AI assistant.

Summary

TaskSeq.OfXXX.Tests.fs had EmptySeq and Immutable modules but no SideEffects module, unlike most other test files in the suite.

This PR adds a SideEffects module with 3 new tests that document an important and subtle aspect of the ofXxx conversion functions: re-iteration semantics.

New tests

  1. ofSeq re-evaluates the underlying source seq on each re-enumeration: Verifies that TaskSeq.ofSeq is lazy — each call to GetAsyncEnumerator creates a fresh IEnumerator from the underlying seq, so side effects in the seq body are re-triggered on every enumeration. After two enumerations of a 3-element side-effecting seq, the counter reaches 6.

  2. ofTaskSeq with lazy seq of tasks re-creates tasks on each re-enumeration: Verifies the same lazy re-evaluation applies to TaskSeq.ofTaskSeq when the input is a lazy seq. On each enumeration, the seq is re-iterated and fresh Task objects are created and run — count goes from 3 to 6 across two enumerations.

  3. ofTaskArray does not re-run tasks on re-enumeration; task results are cached: Provides the complementary case. When TaskSeq.ofTaskArray wraps a fixed array, the Task<'T> objects are created upfront (and run synchronously to completion at array-construction time). Re-enumerating the TaskSeq merely re-awaits the already-completed tasks — their results are cached in the Task object and no computation is re-run (count stays at 3 after both enumerations).

These three tests together serve as executable documentation for the distinction between lazy-seq and fixed-collection variants of the conversion functions.

Test growth

Before After
21 tests 24 tests

Test Status

  • Build: ✅ dotnet build src/FSharp.Control.TaskSeq.Test -c Release — succeeded (0 warnings, 0 errors)
  • Tests: ✅ dotnet test --filter "FullyQualifiedName~TaskSeq.Tests.Conversion-From" -c Release24 passed, 0 failed
  • Format: ✅ dotnet fantomas src/.../TaskSeq.OfXXX.Tests.fs --check — clean

Generated by 🤖 Repo Assist, see workflow run.

Generated by 🌈 Repo Assist, see workflow run. Learn more.

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/repo-assist.md@96b9d4c39aa22359c0b38265927eadb31dcf4e2a

Documents re-iteration semantics for the ofXxx conversion functions:
- ofSeq: re-evaluates the underlying IEnumerable on each re-enumeration
- ofTaskSeq with lazy seq: creates fresh Task objects on each re-enumeration
- ofTaskArray: tasks run once upfront; re-enumeration awaits cached results

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants