What are task continuations? Compare ContinueWith with await and explain the options that control how continuations run.

1. How continuations are stored and run

Task.m_continuationObject:
   null                      -> no continuations
   single object             -> one continuation (common case for await)
   List<object>              -> several

On completion (FinishContinuations):
   for each continuation:
       if it may run inline (and stack depth OK) -> run now on this thread
       else                                       -> queue to its scheduler / sync context

The completing thread decides. If the task was created with RunContinuationsAsynchronously, nothing runs inline.

2. The "unmet condition" gotcha

Task failing = Task.Run(() => throw new InvalidOperationException());
Task onSuccess = failing.ContinueWith(_ => Console.WriteLine("ok"),
    CancellationToken.None, TaskContinuationOptions.OnlyOnRanToCompletion, TaskScheduler.Default);

await onSuccess;   // throws TaskCanceledException, not InvalidOperationException!

The continuation didn't run, so its task is canceled. The original failure is only visible on failing. Code that awaits the continuation chain silently loses the real error.

3. Unwrap

Task<Task> outer = first.ContinueWith(async t => { await Task.Delay(100); Save(t.Result); }, TaskScheduler.Default);
await outer;            // completes at the inner lambda's first await!
await outer.Unwrap();   // completes when the inner async work completes

Task.Run performs this unwrapping automatically for async lambdas; StartNew and ContinueWith don't.

4. Rewriting a ContinueWith chain with await

// Old
LoadAsync().ContinueWith(t =>
{
    if (t.IsFaulted) { Log(t.Exception); return; }
    Render(t.Result);
}, TaskScheduler.FromCurrentSynchronizationContext());

// New
try { Render(await LoadAsync()); }   // resumes on UI context by default in UI apps
catch (Exception ex) { Log(ex); }

Shorter, correct exception flow, correct scheduler by default.

5. Producer-side rules

6. Version notes

7. Try it yourself

1. Run the code example and compare the thread ids of the inline and queued continuations.
2. Use OnlyOnRanToCompletion on a faulting antecedent and await the continuation; observe TaskCanceledException.
3. Reproduce the pool deadlock: complete a TCS inside lock (gate) while the continuation also does lock (gate) from another method on the same thread path... then fix it.
4. Rewrite a three-step ContinueWith chain as async/await and compare exception output.
5. Benchmark ContinueWith vs await for a completed task with [MemoryDiagnoser].

Task<int> work = Task.Run(() => 21 * 2);

// ContinueWith done properly: explicit options and scheduler.
Task logged = work.ContinueWith(
    t => Console.WriteLine($"Completed with {t.Result}"),
    CancellationToken.None,
    TaskContinuationOptions.OnlyOnRanToCompletion | TaskContinuationOptions.ExecuteSynchronously,
    TaskScheduler.Default);

// Async lambda with ContinueWith needs Unwrap.
Task chained = work.ContinueWith(async t =>
{
    await Task.Delay(50);
    Console.WriteLine($"Async continuation saw {t.Result}");
}, TaskScheduler.Default).Unwrap();

await Task.WhenAll(logged, chained);

// Inline completion demo.
var inline = new TaskCompletionSource();
var queued = new TaskCompletionSource(TaskCreationOptions.RunContinuationsAsynchronously);
Task a = Report("inline", inline.Task);
Task b = Report("queued", queued.Task);

var completer = new Thread(() =>
{
    Console.WriteLine($"Completer thread {Environment.CurrentManagedThreadId}");
    inline.SetResult();  // continuation may run right here
    queued.SetResult();  // continuation is queued to the pool
});
completer.Start();
completer.Join();
await Task.WhenAll(a, b);

static async Task Report(string name, Task t)
{
    await t;
    Console.WriteLine($"{name} continuation on thread {Environment.CurrentManagedThreadId}");
}