Runtime & concurrency
using System;
using System.Linq;
using System.Collections.Generic;
using System.Collections.Concurrent;
using System.Reflection;
using System.Linq.Expressions;
using System.Threading;
using System.Threading.Tasks;
var local = new AsyncLocal<string?>();
local.Value = "root";
await Task.CompletedTask.ConfigureAwait(false);
Console.WriteLine($"ambient:{local.Value}");
Console.WriteLine($"suppressed:{ExecutionContext.IsFlowSuppressed()}");
Reveal answer and reasoning
The portable output is ambient:root and suppressed:False. The program stores root in AsyncLocal, then awaits an already completed Task with ConfigureAwait false. That option does not erase the ambient value or enable suppression. No SuppressFlow call appears in this snippet, and the completed await does not establish any particular rescheduling or OS-thread transition.
The separate desktop program schedules work while flow is suppressed and reports worker none, parent root, and suppression false after restoration. Those are not extra lines in this companion. A common wrong trace changes ambient to none merely because false appears in ConfigureAwait, or assumes IsFlowSuppressed must become true. The actual mechanisms have different scopes. Keep the parent slot, queued worker capture, and continuation-context preference separate rather than translating every context-related option into one imagined global switch.
What a strong answer covers
- Ambient root remains present.
- The snippet never calls SuppressFlow.
- An already completed await proves no thread hop.
Common pitfall
Inventing a suppression scope or erased AsyncLocal value from ConfigureAwait(false) alone.
Follow-up questions
- What would scheduling after restoration inherit?
- Why is suppression restored before awaiting the external task?
Self-review
Choose what to revisit. These marks are your own assessment and are separate from lesson completion.