Debugging scenarioHard~12 minAsync & Concurrency Essentials / 11 of 17

Interview question

A production API sometimes hangs under load. You find code calling `.Result` on async methods. What is the risk and how would you fix it?

Sync-over-async deadlock risk

Investigate deadlocks or starvation caused by blocking on async code with Result, Wait, or GetAwaiter().GetResult().

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Calling .Result or .Wait() blocks the current thread until the Task finishes. In a web service, enough blocked requests can exhaust available workers and delay the continuations needed to complete other requests. The usual fix is to make the call chain asynchronous from the controller through its dependencies and await the operation. I also verify that the underlying dependency offers real asynchronous I/O rather than hiding blocking work behind a Task-shaped API.

Full answer below

Practice focus

Sync-over-async blocking, deadlock-style behavior, thread-pool starvation, request pipeline impact, and safe migration to async all the way.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
Blocking on asynchronous work defeats thread release and can starve an ASP.NET Core service under load. Classic synchronization-context deadlocks are only one failure mode; request-thread exhaustion and delayed continuations are the common server-side symptoms.
Calling .Result or .Wait() blocks the current thread until the Task finishes. In a web service, enough blocked requests can exhaust available workers and delay the continuations needed to complete other requests. The usual fix is to make the call chain asynchronous from the controller through its dependencies and await the operation. I also verify that the underlying dependency offers real asynchronous I/O rather than hiding blocking work behind a Task-shaped API.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
For example, if a controller calls a service that blocks on _client.GetAsync(...).Result, each request can hold a thread while waiting for I/O. Under load, enough blocked threads can prevent continuations and other requests from running promptly. I would change the service API to return Task, await the dependency, pass cancellation tokens, and add tests around timeout/error behavior. The trade-off is that async migration can touch many method signatures, so I would do it intentionally rather than mixing blocking and async in the same path.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would first confirm the symptom with thread-pool counters, request duration, dumps, and dependency latency. Then I would remove sync-over-async from hot paths and avoid replacing it with Task.Run unless I am isolating a temporary synchronous dependency with bounded concurrency. If the blocking is around a legacy library, I would limit access, add timeouts, and plan a real async replacement. I would monitor thread-pool queue length, active requests, timeout rates, and CPU after the fix because the failure mode may shift from hangs to downstream saturation.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Fixing the problem by wrapping .Result in Task.Run everywhere.
Migrating only one method and leaving blocking higher in the call chain.
Ignoring cancellation and timeouts during the migration.
Assuming ASP.NET Core cannot suffer because it has no classic UI synchronization context.
Not measuring thread-pool behavior before and after the fix.

Red flagsCandidateRed flagsSignals that an interviewer may treat as risky.Open details

Details

A weak answer only says 'deadlock' without explaining the actual server symptom. I expect the candidate to connect blocking, thread-pool pressure, and async migration strategy.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

Why can sync-over-async be bad even without a UI SynchronizationContext?
How would you migrate a large service from sync to async safely?
When would Task.Run be a temporary containment strategy?
What production metrics would confirm the issue?

Continue the section

Next in Async & Concurrency Essentials: Thread Pool Starvation

Step 12 of 17

Thread pool starvation in .NET APIs

Opening drill

Debugging scenarioHard~12 minAsync & Concurrency Essentials / 11 of 17

Interview question

A production API sometimes hangs under load. You find code calling `.Result` on async methods. What is the risk and how would you fix it?

Sync-over-async deadlock risk

Investigate deadlocks or starvation caused by blocking on async code with Result, Wait, or GetAwaiter().GetResult().

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

Sync-over-async blocking, deadlock-style behavior, thread-pool starvation, request pipeline impact, and safe migration to async all the way.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
Blocking on asynchronous work defeats thread release and can starve an ASP.NET Core service under load. Classic synchronization-context deadlocks are only one failure mode; request-thread exhaustion and delayed continuations are the common server-side symptoms.
Calling .Result or .Wait() blocks the current thread until the Task finishes. In a web service, enough blocked requests can exhaust available workers and delay the continuations needed to complete other requests. The usual fix is to make the call chain asynchronous from the controller through its dependencies and await the operation. I also verify that the underlying dependency offers real asynchronous I/O rather than hiding blocking work behind a Task-shaped API.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
For example, if a controller calls a service that blocks on _client.GetAsync(...).Result, each request can hold a thread while waiting for I/O. Under load, enough blocked threads can prevent continuations and other requests from running promptly. I would change the service API to return Task, await the dependency, pass cancellation tokens, and add tests around timeout/error behavior. The trade-off is that async migration can touch many method signatures, so I would do it intentionally rather than mixing blocking and async in the same path.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would first confirm the symptom with thread-pool counters, request duration, dumps, and dependency latency. Then I would remove sync-over-async from hot paths and avoid replacing it with Task.Run unless I am isolating a temporary synchronous dependency with bounded concurrency. If the blocking is around a legacy library, I would limit access, add timeouts, and plan a real async replacement. I would monitor thread-pool queue length, active requests, timeout rates, and CPU after the fix because the failure mode may shift from hangs to downstream saturation.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Fixing the problem by wrapping .Result in Task.Run everywhere.
Migrating only one method and leaving blocking higher in the call chain.
Ignoring cancellation and timeouts during the migration.
Assuming ASP.NET Core cannot suffer because it has no classic UI synchronization context.
Not measuring thread-pool behavior before and after the fix.

Red flagsCandidateRed flagsSignals that an interviewer may treat as risky.Open details

Details

A weak answer only says 'deadlock' without explaining the actual server symptom. I expect the candidate to connect blocking, thread-pool pressure, and async migration strategy.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

Why can sync-over-async be bad even without a UI SynchronizationContext?
How would you migrate a large service from sync to async safely?
When would Task.Run be a temporary containment strategy?
What production metrics would confirm the issue?

Continue the section

Next in Async & Concurrency Essentials: Thread Pool Starvation

Step 12 of 17

Thread pool starvation in .NET APIs

A production API sometimes hangs under load. You find code calling `.Result` on async methods. What is the risk and how would you fix it?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

A production API sometimes hangs under load. You find code calling `.Result` on async methods. What is the risk and how would you fix it?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section