Debugging scenarioMedium~7 min

Interview question

An ASP.NET Core endpoint starts writing a response and then throws. Why might the exception handler be unable to return a normal Problem Details response?

Response started and late exceptions in ASP.NET Core

Explains why committed headers cannot be replaced, how streaming failures behave, and how middleware preserves response ownership.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

ASP.NET Core does not buffer every response body by default. Once the response starts, its status code and headers have been sent and cannot be replaced with a different 500 response or Problem Details document. The response can start when code writes or flushes the body, starts it explicitly, or a formatter begins producing output. HttpResponse.HasStarted tells middleware whether that boundary has been crossed. Exception-handling middleware placed early can catch downstream exceptions, log them, and create a clean error response only when the original response has not started. If bytes are already committed, the server usually has to stop further output and terminate or reset the response, so the client may receive a partial payload rather than a second valid response document.

Full answer below

Practice focus

Response buffering, headers, `HasStarted`, `OnStarting`, exception middleware, streaming, partial responses, cancellation, and connection abort behavior.

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
Central exception handling works cleanly only while the server still owns an uncommitted response. Streaming and early writes change what recovery is possible on the same HTTP exchange.
ASP.NET Core does not buffer every response body by default. Once the response starts, its status code and headers have been sent and cannot be replaced with a different 500 response or Problem Details document. The response can start when code writes or flushes the body, starts it explicitly, or a formatter begins producing output. HttpResponse.HasStarted tells middleware whether that boundary has been crossed. Exception-handling middleware placed early can catch downstream exceptions, log them, and create a clean error response only when the original response has not started. If bytes are already committed, the server usually has to stop further output and terminate or reset the response, so the client may receive a partial payload rather than a second valid response document.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I set status and headers before writing, and I register OnStarting callbacks before downstream code when a header must be finalized immediately before commitment. Code after await next checks HasStarted before attempting late header changes. For a small response that must be all-or-nothing, bounded buffering can delay commitment, but buffering large files or streams defeats streaming and increases memory and latency. A streaming protocol needs its own failure semantics, such as a framed error message, a resumable cursor, or a client-visible incomplete stream; appending JSON Problem Details to half of a JSON array does not create a valid recovery response.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I distinguish three outcomes: a clean mapped error before commitment, a client cancellation while writing, and an application failure after a partial response. They have different logging severity and reliability meaning. I preserve the original exception and trace context, avoid logging expected disconnects as server defects, and record whether the response had started and how many bytes or items were emitted when that is safely observable. OnCompleted is useful for cleanup or telemetry after the server finishes its response path, but it is not proof that the client consumed the body. For large exports and long streams I make generation restartable or produce a durable artifact before download when partial delivery is unacceptable. Integration tests use a response that flushes early and then fails, because ordinary unit tests with buffered in-memory results can hide the exact boundary that caused the production behavior.

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

Trying to change the status code after writing the response body.
Appending a second JSON error document to a partially written payload.
Buffering an unbounded export merely to preserve generic exception mapping.
Treating every client disconnect as an unexpected server exception.

Red flagsCandidateSigns the approach is fragileSignals that an interviewer may treat as risky.Open details

Details

Late response mutation fails intermittently under real streaming behavior.
Exception middleware is registered after components it is expected to catch.
Clients cannot distinguish a complete stream from a truncated one.
Tests never flush output before exercising the failure path.

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.

What causes an ASP.NET Core response to start?
When would OnStarting help?
How would you design errors for a streaming endpoint?

Continue practice

Move to the linked follow-up, next path step, prerequisite, or deeper variant.

2 linked

Go deeper

Practice the next layer of the same subject.

Request body boundaries

Prerequisite

Review this first if the current drill feels shaky.

Error Handling Strategy

Opening drill

Debugging scenarioMedium~7 min

Interview question

An ASP.NET Core endpoint starts writing a response and then throws. Why might the exception handler be unable to return a normal Problem Details response?

Response started and late exceptions in ASP.NET Core

Explains why committed headers cannot be replaced, how streaming failures behave, and how middleware preserves response ownership.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

Response buffering, headers, `HasStarted`, `OnStarting`, exception middleware, streaming, partial responses, cancellation, and connection abort behavior.

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
Central exception handling works cleanly only while the server still owns an uncommitted response. Streaming and early writes change what recovery is possible on the same HTTP exchange.
ASP.NET Core does not buffer every response body by default. Once the response starts, its status code and headers have been sent and cannot be replaced with a different 500 response or Problem Details document. The response can start when code writes or flushes the body, starts it explicitly, or a formatter begins producing output. HttpResponse.HasStarted tells middleware whether that boundary has been crossed. Exception-handling middleware placed early can catch downstream exceptions, log them, and create a clean error response only when the original response has not started. If bytes are already committed, the server usually has to stop further output and terminate or reset the response, so the client may receive a partial payload rather than a second valid response document.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I set status and headers before writing, and I register OnStarting callbacks before downstream code when a header must be finalized immediately before commitment. Code after await next checks HasStarted before attempting late header changes. For a small response that must be all-or-nothing, bounded buffering can delay commitment, but buffering large files or streams defeats streaming and increases memory and latency. A streaming protocol needs its own failure semantics, such as a framed error message, a resumable cursor, or a client-visible incomplete stream; appending JSON Problem Details to half of a JSON array does not create a valid recovery response.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I distinguish three outcomes: a clean mapped error before commitment, a client cancellation while writing, and an application failure after a partial response. They have different logging severity and reliability meaning. I preserve the original exception and trace context, avoid logging expected disconnects as server defects, and record whether the response had started and how many bytes or items were emitted when that is safely observable. OnCompleted is useful for cleanup or telemetry after the server finishes its response path, but it is not proof that the client consumed the body. For large exports and long streams I make generation restartable or produce a durable artifact before download when partial delivery is unacceptable. Integration tests use a response that flushes early and then fails, because ordinary unit tests with buffered in-memory results can hide the exact boundary that caused the production behavior.

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

Trying to change the status code after writing the response body.
Appending a second JSON error document to a partially written payload.
Buffering an unbounded export merely to preserve generic exception mapping.
Treating every client disconnect as an unexpected server exception.

Red flagsCandidateSigns the approach is fragileSignals that an interviewer may treat as risky.Open details

Details

Late response mutation fails intermittently under real streaming behavior.
Exception middleware is registered after components it is expected to catch.
Clients cannot distinguish a complete stream from a truncated one.
Tests never flush output before exercising the failure path.

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.

What causes an ASP.NET Core response to start?
When would OnStarting help?
How would you design errors for a streaming endpoint?

Continue practice

Move to the linked follow-up, next path step, prerequisite, or deeper variant.

2 linked

Go deeper

Practice the next layer of the same subject.

Request body boundaries

Prerequisite

Review this first if the current drill feels shaky.

Error Handling Strategy

An ASP.NET Core endpoint starts writing a response and then throws. Why might the exception handler be unable to return a normal Problem Details response?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice

Go deeper

Prerequisite

An ASP.NET Core endpoint starts writing a response and then throws. Why might the exception handler be unable to return a normal Problem Details response?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice

Go deeper

Prerequisite