Fix processor correctness: lazy re-enumeration, broken cancellation on dispose, hung awaiters

[thomhurst]

Summary

Two commits: correctness fixes to the processor core, then removal of dead code and arbitrary limits. Found during a full review of the library core.

Commit 1 - Correctness fixes

Input enumerated up to 5 times (now exactly once). TaskWrappers was a lazy items.Select(...) query, re-enumerated by validation (.Any()), Process(), Task.WhenAll, CancelAll() and disposal. One-shot sources (DB readers, File.ReadLines) broke, and side-effecting iterators re-ran their side effects. Wrappers are now materialized once in the constructor, which also removes the ConcurrentDictionary that existed only to keep completion-source identity stable across re-enumerations (and allocated a fresh TCS per index on every enumeration via the GetOrAdd value overload).

Disposal never cancelled anything. DisposeAsync set _disposed = true before calling CancelAll(), whose _disposed guard then made it a no-op - so disposal waited up to 30s for tasks to finish naturally. Cancellation now runs unconditionally during disposal via a private core method.

CancelAll() on result processors blocked the calling thread up to 30s. The result base registered sync-over-async Dispose as the cancellation callback. Both bases now register CancelAll, and registration happens at Start() rather than in the constructor - so a token cancelled during construction can no longer fire a callback on a partially constructed instance (NRE via the unassigned _cancellationTokenSource / TaskWrappers).

Awaiters could hang forever. StartProcessing discarded the Process() task. A fault outside the per-item wrappers (cancellation plumbing, previously also enumeration) left completion sources permanently unfinished. Process() faults are now routed into all unfinished completion sources.

Inline continuations. Completion sources are now created with TaskCreationOptions.RunContinuationsAsynchronously, so user continuations no longer run inline on the completing thread.

Exception fidelity. The completed-task fast path used GetBaseException(), which dropped all but one exception on multi-fault tasks and diverged from the awaited path. Faulted tasks now propagate Exception.InnerExceptions in full.

Non-blocking sync Dispose(). Previously Task.Run(...).Wait(30s). It now cancels and releases immediately; DisposeAsync keeps the bounded 30s graceful wait for in-flight work (now waiting on the actual process task rather than the completion sources, which complete instantly once cancelled).

Consistent cancellation flow in the rate-limited/timed processors (was a mix of CancellationToken.None, missing Task.Run tokens, and stale comments).

Commit 2 - Cleanup

• Removed GetPerformanceWarning (computed then discarded in four constructors) and the never-enforced MAX_PARALLELISM constant.
• Removed the arbitrary caps: 10,000 max tasks, 10,000 max batch size, 24h max timespan. These threw on legitimate large workloads. Negative/zero validation remains.
• Added the missing parallelism/batch/timespan validation to the result processor variants so all processors validate alike.
• Stripped unused IEquatable/operators/Deconstruct/GetHashCode and AggressiveInlining (a no-op on async methods) from the TaskWrapper structs.
• Removed the completed-task fast paths in ParallelExtensions - rethrowing GetBaseException() destroyed stack traces; awaiting is equivalent and correct.
• LangVersion preview -> latest (no preview features remain).
• README disposal notes updated to match.

Behaviour changes to be aware of

• Constructors now enumerate the input eagerly, so iterator exceptions surface at builder-call time instead of hanging awaiters.
• Sync Dispose() no longer blocks up to 30s.
• Counts/batch sizes over 10,000 and timespans over 24h are now accepted.
• Public but incidental TaskWrapper members (equality operators, Deconstruct) were removed - technically binary-breaking, happy to drop that commit if you want to keep them.

Testing

• Library builds clean on all TFMs (net6.0/net8.0/net9.0/netstandard2.0), 0 warnings.
• Full TUnit suite: 507/507 passing (one test removed with the equality ceremony it exercised).
• Note: EnumerableAsyncProcessor.Example and EnumerableAsyncProcessor.Pipeline already fail to build on main (pre-existing: example references a non-existent ToAsyncEnumerable; pipeline targets net9.0 with net10-only ModularPipelines v3 packages) - untouched here.

[greptile-apps]

Greptile Summary

This PR fixes processor lifecycle and execution correctness across the library. The main changes are:

• Materializes input sequences once to prevent lazy re-enumeration.
• Corrects cancellation, disposal, and process-fault propagation.
• Preserves complete task exceptions and runs continuations asynchronously.
• Reworks rate-limited execution around a worker pool.
• Aligns validation and result streaming across processor variants.
• Updates the build pipeline and prepares the package for v4.0.0.

Confidence Score: 5/5

This looks safe to merge.

• The public wrapper API removal is consistent with the planned v4.0.0 release.
• No separate compatibility break or incomplete fix was found.

Important Files Changed

Filename	Overview
EnumerableAsyncProcessor/TaskWrapper.cs	Simplifies the public wrapper structs while retaining their construction and processing behavior.
EnumerableAsyncProcessor/ProcessorLifecycle.cs	Centralizes processor startup, cancellation, fault propagation, and disposal.
EnumerableAsyncProcessor/WorkerPool.cs	Introduces shared worker-pool execution for bounded and rate-limited processing.
GitVersion.yml	Sets the next package version to the v4.0.0 major release.

_{Reviews (9): Last reviewed commit: "chore: remove accidentally committed too..." | Re-trigger Greptile}