Runtime & concurrency
Reveal answer and reasoning
ConfigureAwait false changes an awaiter's continuation-context policy; it does not erase AsyncLocal data or suppress execution-context capture in general. It also does not force a physical thread switch, especially when the awaited operation is already complete. SuppressFlow instead changes capture for work scheduled while suppression is active, and its restoration token has an ownership scope that must be respected.
The desktop example schedules Task.Run inside a short synchronous suppression scope, restores it before awaiting, and observes no inherited root value in that worker. The parent still retains root. A common wrong answer awaits inside the suppression scope indiscriminately or describes either operation as removing all context. Ambient state, continuation affinity, scheduling-time capture, and physical restoration are separate concerns. Choose an explicit propagation policy for detached work rather than using suppression as an unexplained optimization or assuming every library await must lose tracing data.
What a strong answer covers
- Continuation policy differs from execution-context capture.
- ConfigureAwait false does not force a thread switch.
- Restore suppression before arbitrary await continuation.
Common pitfall
Equating ConfigureAwait(false) with erasing ambient data or safely carrying AsyncFlowControl across await.
Follow-up questions
- Does suppression clear the caller's current AsyncLocal immediately?
- What should detached work copy explicitly?
Self-review
Choose what to revisit. These marks are your own assessment and are separate from lesson completion.