Senior · Design · Suppressed flow differs from ConfigureAwait

How would you schedule deliberately detached work with a precise context and ownership policy?

Think through your answer before opening the explanation.

Runtime & concurrency

Reveal answer and reasoning

Decide which ambient data the detached operation should inherit, receive explicitly, or omit. If full flow suppression is appropriate, keep its scope synchronous around scheduling and restore it on the creating thread before any arbitrary await. Retain the scheduled task and define how its completion, cancellation, and failures are owned; suppression is not permission to abandon unobserved background work.

Test inherited and suppressed scheduling separately, plus restoration of the parent's context. If UI or custom-scheduler affinity matters, test that independently from AsyncLocal propagation. The wrong design treats ConfigureAwait false as guaranteed detachment or carries AsyncFlowControl across an await that may resume elsewhere. It also may suppress useful tracing or identity data without replacing the application contract explicitly. Context policy should be a deliberate part of the operation boundary, not a slogan that all context is either good or expensive and must disappear.

What a strong answer covers

  • Choose data propagation explicitly.
  • Keep suppression scheduling scope synchronous and restored.
  • Own the detached task and test affinity separately.

Common pitfall

Using context suppression to justify unobserved fire-and-forget work or an undefined data-propagation policy.

Follow-up questions

  1. How would a background service receive an explicit correlation ID?
  2. What if the queued task fails after the request ends?

Self-review

Choose what to revisit. These marks are your own assessment and are separate from lesson completion.

Primary references

Open lesson and code ↗

← All interview questions