C# async/await Correctness: Avoid async void, False Completion, and Cancellation Mistakes

C# async/await correctness is not achieved merely by adding the async modifier. A reliable design keeps completion, failure, cancellation, and ownership observable across the entire call chain. This guide turns recurring failure patterns into reviewable rules and verifies three important behaviors in a fixed .NET 8 test project.

The correctness contract behind async and await

An asynchronous method is correct when its caller can observe completion, receive failures, distinguish cancellation, and understand who owns work that outlives the immediate call. Those properties matter more than whether the source code happens to contain the async keyword.

A well-formed asynchronous boundary carries four pieces of information. It exposes a Task that represents the operation. It stores failure in that task so an upstream caller can handle or translate the exception. It makes sequential versus concurrent execution an explicit decision. It also treats cancellation as cooperation: one component requests cancellation, while the component doing the work must observe that request and stop at a safe point.

The purpose of await is therefore not to make every operation faster. It establishes a composable completion relationship. The current method can yield control without occupying its thread, then continue when the awaited task finishes. If that task fails, the failure is rethrown at the await point. Tests can wait for the same boundary, request handlers can finish required work before constructing a response, and ordinary exception handling remains connected to the calling flow.

During review, identify every asynchronous boundary and ask three questions. Who owns the lifetime of this operation? Who observes its result and failure? What happens when the caller stops waiting, requests cancellation, or begins shutdown? An unanswered question indicates an incomplete design even when the code compiles and appears to work during a quick manual run.

This contract also prevents misleading terminology. Starting work is not the same as completing work. Timing out a wait is not necessarily stopping the underlying operation. A task that is not faulted at one instant has not necessarily succeeded. These distinctions should be visible in method signatures, control flow, logs, and tests instead of being left as assumptions.

Why List.ForEach with an async lambda creates false completion

List.ForEach accepts a synchronous Action. When it receives an async lambda, that lambda becomes async void, so the outer call cannot collect or await the individual operations and may return before any item has completed.

The defect is caused by the delegate type rather than by the visual appearance of the lambda. A reviewer sees await inside the callback and may reasonably assume that the surrounding method waits. However, Action returns no value, so there is no task for List.ForEach to expose. Every callback can start, encounter its first incomplete await, and yield. The ForEach call then finishes even though the item operations remain pending.

That behavior also damages failure handling. A normal task-returning method stores its exception in its task, and the caller observes that exception by awaiting it. An async-void callback has no such task. Exceptions raised after the asynchronous continuation are not composed into an outer operation that an ordinary caller can await. A surrounding try/catch around the initial ForEach invocation does not provide the same guarantee.

Use a regular foreach with await when order matters or when processing must stop after the first failure. Use Select to create a concrete collection of tasks followed by await Task.WhenAll(tasks) when independent operations should proceed concurrently. The first pattern states sequential intent. The second pattern exposes a shared completion boundary and allows the caller to know when every item has finished.

Do not confuse “all callbacks were invoked” with “all item work completed.” If later code reads state produced by those operations, only an awaited completion boundary establishes the necessary ordering. An arbitrary delay is not a substitute because it depends on scheduling and machine conditions rather than on the actual state of the work.

Review delegate signatures whenever an async lambda is passed to Action, an event callback, or an API that does not return task objects. Also inspect Select(async ...) carefully: producing an enumerable of tasks is only the first step. The tasks must be materialized and awaited, otherwise deferred enumeration or an abandoned sequence can create a different form of lost work.

async void, abandoned tasks, and observable failures

Except for event handlers whose framework signature requires void, public asynchronous methods should return Task. Discarding a task removes the caller’s ability to observe completion, failure, or cancellation and prevents reliable coordination with subsequent work.

The central limitation of async void is the absence of an awaitable object. The caller cannot wait for the operation, a unit test cannot directly synchronize with its completion, and asynchronous exceptions do not travel through a normal task await. User-interface or framework events may require a void signature, but the handler should remain a thin adapter. It should call a task-returning core method and handle failure explicitly at the event boundary.

Writing _ = SomeAsync() documents that a returned task is deliberately ignored, but it does not create reliability. If the operation contributes to the current response or state transition, await it. If the operation genuinely has an independent lifetime, transfer it to a managed background component with bounded admission, failure recording, retry policy where appropriate, graceful draining, and health visibility. The important action is ownership transfer, not suppressing a compiler warning.

Failure handling should follow that ownership. A lower layer should catch an exception only when it can recover or add actionable context. Otherwise it should preserve the faulted task and allow the owner to decide. An empty catch converts a failed operation into apparent success and removes diagnostic evidence. With Task.WhenAll, retain a mapping between each input and its task so a failure can be tied to the affected item without relying on ambiguous timing.

A response should be created only after all work required for that response has completed. Starting an asynchronous callback, immediately serializing a mutable result, and modifying the result later creates a race. The caller receives whichever state happened to exist at serialization time. The correction is not a longer delay. It is a deterministic boundary: await the operation, obtain an immutable or stable result, and only then build the response.

This rule applies equally to validation, transformation, persistence in a sandbox test, and aggregation. If the outcome changes what the caller should receive, the work belongs to the current call. If it does not belong there, the architecture needs an explicit handoff and a separately observable status model.

Wait, Result, Task.Status, and cancellation semantics

Synchronous Wait or Result occupies the current thread, while Task.Status is only a snapshot taken at one instant. Neither replaces awaiting the task and then branching explicitly on successful completion, failure, or cancellation.

Calling .Wait() or reading .Result turns a potentially nonblocking asynchronous path into synchronous blocking. In an environment with a synchronization context it can participate in circular waiting. Under server load it can also keep a thread unavailable while useful work is pending elsewhere. The general design rule is “async all the way”: return and await tasks from the entry boundary downward rather than repeatedly crossing between asynchronous and blocking code.

Task.Status is not a prediction of eventual success. A newly created task is usually incomplete. Checking that it is “not faulted” only describes the current instant, does not prove that it will succeed later, and can overlook cancellation. When a result is required, await the task. Continue on success, handle a failure in catch, and separate cancellation when the application needs different policy. IsCompletedSuccessfully is useful only when an independently established precondition guarantees that the task has already completed; it is not a waiting mechanism.

Timeout and cancellation require an additional distinction. WaitAsync can cause the task returned to the waiter to finish because the timeout elapsed or the caller’s cancellation request was observed. That behavior defines the waiting boundary. It does not force an arbitrary original operation to stop. If the original work ignores cancellation, it may remain active after the waiter has moved on.

A cancellable method should accept a CancellationToken, pass it to downstream APIs that support cancellation, and check it at safe loop or stage boundaries. State transitions must remain consistent when cancellation occurs. When an older component cannot cooperate, describe the timeout result as “the wait ended; operation state is unknown,” not as “the operation stopped.” Before retrying, account for the still-running attempt through operation identity and idempotent design.

This distinction has direct testing value. A deterministic test can gate the original task, cancel only the wait, and assert that the original remains incomplete. It can then release the gate and confirm that the original task finishes. That observation proves the API boundary without relying on a race, external service, or guessed delay.

Verification and safe reproduction on a fixed .NET 8 SDK

The scheduler executed this test with .NET SDK 8.0.100 targeting net8.0. It uses only in-memory TaskCompletionSource gates and produced seven PASS lines, with no external account, remote write, irreversible data operation, or benchmark claim.

Prerequisites are a writable empty test directory and the .NET SDK version 8.0.100. A global.json file must pin that exact SDK with roll-forward disabled. Reproduce the checks as follows:

Create a net8.0 console project and add global.json with SDK version 8.0.100 and rollForward set to disable.
Add controlled gates for the List.ForEach callback, a Task.WhenAll collection, and an original task that does not observe the waiter's cancellation request.
Run dotnet run --configuration Release; every assertion must print PASS, and any thrown assertion or nonzero process exit is a failure.

using System.Collections.Concurrent;

static void Assert(bool ok, string message)
{
    if (!ok) throw new InvalidOperationException("FAIL: " + message);
    Console.WriteLine("PASS: " + message);
}

var items = new[] { 1, 2, 3 };
var gates = items.ToDictionary(x => x, _ => new TaskCompletionSource());
var completed = new ConcurrentBag();
items.ToList().ForEach(async x => { await gates[x].Task; completed.Add(x); });
Assert(completed.IsEmpty, "ForEach returned before callbacks completed");
foreach (var gate in gates.Values) gate.SetResult();
await Task.Delay(50);

var tasks = items.Select(async x => { await Task.Yield(); return x; }).ToArray();
var results = await Task.WhenAll(tasks);
Assert(results.SequenceEqual(items), "WhenAll observed every result");

var release = new TaskCompletionSource();
var original = Task.Run(async () => await release.Task);
using var cts = new CancellationTokenSource(TimeSpan.FromMilliseconds(50));
try { await original.WaitAsync(cts.Token); } catch (OperationCanceledException) { }
Assert(!original.IsCompleted, "original task continued after waiter cancellation");
release.SetResult();
await original;

The first check proves that List.ForEach has returned while its gated callbacks are still incomplete. That is a direct observation of the missing aggregate task. The second check proves that Task.WhenAll provides a common completion point and exposes all results after every child task finishes. The third check proves that cancellation of the waiter leaves a noncooperative original task incomplete until the test explicitly releases it.

The full scheduler run passed seven assertions: ForEach returned before gated work completed; the async-void callbacks completed only after release; WhenAll stayed incomplete while children were gated; awaiting WhenAll observed all results; WaitAsync observed cancellation; the original work did not stop when the waiter canceled; and the original task completed successfully after release. These are functional assertions, not throughput measurements or success-rate estimates.

The test is intentionally narrow. It does not claim that one concurrency pattern is universally faster, and it does not depend on thread timing for its important assertions. TaskCompletionSource supplies deterministic boundaries. The short delay only allows already-released async-void callbacks to resume so their eventual completion can be observed; the central false-completion assertion occurs before release and therefore does not depend on that delay.

A review and refactoring decision framework

First decide whether an operation affects the current result or belongs to independently managed background work. Then choose sequential, bounded concurrent, or cancellation-aware structure while preserving a testable completion boundary and an observable failure path.

Work required to calculate or validate the current result must be awaited before that result is returned. Independent operations that may proceed concurrently can be represented as a concrete task collection and joined with Task.WhenAll. Work with a genuinely separate lifetime should be transferred to an owned background component rather than launched casually from a request method.

For collection processing, select semantics before syntax. Use foreach plus await when ordering matters, when operations depend on previous outputs, or when processing should stop at the first failure. Create and await a task collection when items are independent and concurrent execution is intentional. If a resource has a capacity limit, introduce explicit bounded concurrency and verify the bound in a controlled test rather than creating an unlimited number of operations.

For failure handling, keep the task until its owner has observed it. Avoid async void outside required event signatures. Avoid empty catches. Do not infer success from a status snapshot. In tests, inject a controlled failure into one child operation and assert that the owner receives it at the await boundary. Preserve item identity so diagnostics identify which operation failed without exposing private or environment-specific values.

For cancellation, document whether an API cancels the wait or cooperatively cancels the work. Pass CancellationToken through supporting calls and check it at safe boundaries. When cooperation is impossible, keep the original operation visible after timeout, avoid an automatic duplicate attempt, and expose an unknown or still-running state until ownership can establish the outcome.

For response construction, prohibit mutation by abandoned callbacks after serialization begins. Gather the required values through awaited tasks, convert them into a stable result, and then serialize. A deterministic gate test can prove that the response path does not finish while required work is blocked. This is stronger than a sleep-based test because it waits on state rather than elapsed time.

Finally, encode the rules in review automation where practical. Compiler warnings can identify some unawaited paths, but human review still has to inspect delegate types, ownership transfer, retry policy, and cancellation meaning. A small fixed-version reproduction project belongs beside the design note because framework upgrades can rerun the same behavioral contract without relying on recollection.

Conclusion

Reliable async/await code gives every operation an owner, an observable completion point, a failure observer, and an explicit cancellation contract. Avoiding async void and unmanaged abandoned tasks removes false completion and makes race conditions testable rather than mysterious.

The refactoring order is concrete. Convert non-event async-void methods to task-returning methods. Locate discarded or unawaited tasks. Replace asynchronous List.ForEach callbacks with sequential foreach or a task collection joined by Task.WhenAll. Then define cooperative cancellation, state after timeout, and deterministic reproduction tests.

The core conclusions were cross-checked against Microsoft's official C# asynchronous programming guidance, its Task exception-handling documentation, and the .NET 8 WaitAsync API reference. The local net8.0 run confirmed the three selected behaviors. The source note contributed durable technical concepts only; environment-specific names and sensitive operational details were not carried into this public draft.