Concept questionMedium~7 minASP.NET Core Framework / 8 of 26

Interview question

How would you use CancellationToken in an ASP.NET Core API endpoint?

How should CancellationToken be used in ASP.NET Core APIs?

Propagates request cancellation through async dependencies while keeping committed side effects and timeout policy explicit.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I accept the request CancellationToken in the endpoint and pass it through every cancellable async dependency, including EF Core queries and outbound HTTP calls. ASP.NET Core cancels that token when the request is aborted, so work that no longer has a caller can stop early. Cancellation is cooperative: each operation must observe the token and either stop or complete consistently. I do not treat cancellation as rollback for a database commit, payment, or published message.

Full answer below

Practice focus

request-abort behavior, cooperative cancellation, EF Core/HTTP propagation, side effects, and resource protection

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
Request cancellation protects server capacity when the caller goes away, but it is cooperative and cannot undo a side effect that already crossed its commit boundary.
I accept the request CancellationToken in the endpoint and pass it through every cancellable async dependency, including EF Core queries and outbound HTTP calls. ASP.NET Core cancels that token when the request is aborted, so work that no longer has a caller can stop early. Cancellation is cooperative: each operation must observe the token and either stop or complete consistently. I do not treat cancellation as rollback for a database commit, payment, or published message.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
For a read endpoint, propagation is straightforward because abandoning an unfinished query or HTTP call does not create a business inconsistency. For a write, I define the point after which the operation must finish reliably even if the client disconnects. If a report request becomes durable after a job record and outbox message are committed, the worker continues independently and the client can query status later. The trade-off is between saving resources before commitment and preserving a clear outcome after commitment.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I keep request cancellation, dependency timeouts, and host shutdown as related but separate signals. A client can remain connected while a dependency stalls, so each dependency still needs an explicit timeout inside the endpoint's latency budget. Once a write reaches its commit or publish boundary, I either complete it reliably or hand it to durable work rather than abandoning it halfway. An OperationCanceledException is expected when the relevant token was cancelled, so telemetry records it separately from faults and avoids noisy error alerts. Background work must not retain the request token or HttpContext; it copies the required data and uses the worker's shutdown token instead.

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

Creating a new token and ignoring the request token
Passing the token only to the first method
Assuming cancellation rolls back external side effects
Logging every cancellation as an error
Swallowing OperationCanceledException without understanding the cause

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

Details

Does not know cancellation is cooperative
Confuses timeout with cancellation
Ignores downstream EF/HTTP calls
Treats cancelled writes as safely rolled back

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.

How is timeout different from cancellation?
What if cancellation happens after a side effect?
How would you pass cancellation into EF Core?
Should request cancellation be logged as an error?

Continue the section

Next in ASP.NET Core Framework: Middleware vs Filters

Step 9 of 26

Middleware vs filters in ASP.NET Core

Opening drill

Concept questionMedium~7 minASP.NET Core Framework / 8 of 26

Interview question

How would you use CancellationToken in an ASP.NET Core API endpoint?

How should CancellationToken be used in ASP.NET Core APIs?

Propagates request cancellation through async dependencies while keeping committed side effects and timeout policy explicit.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

request-abort behavior, cooperative cancellation, EF Core/HTTP propagation, side effects, and resource protection

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
Request cancellation protects server capacity when the caller goes away, but it is cooperative and cannot undo a side effect that already crossed its commit boundary.
I accept the request CancellationToken in the endpoint and pass it through every cancellable async dependency, including EF Core queries and outbound HTTP calls. ASP.NET Core cancels that token when the request is aborted, so work that no longer has a caller can stop early. Cancellation is cooperative: each operation must observe the token and either stop or complete consistently. I do not treat cancellation as rollback for a database commit, payment, or published message.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
For a read endpoint, propagation is straightforward because abandoning an unfinished query or HTTP call does not create a business inconsistency. For a write, I define the point after which the operation must finish reliably even if the client disconnects. If a report request becomes durable after a job record and outbox message are committed, the worker continues independently and the client can query status later. The trade-off is between saving resources before commitment and preserving a clear outcome after commitment.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I keep request cancellation, dependency timeouts, and host shutdown as related but separate signals. A client can remain connected while a dependency stalls, so each dependency still needs an explicit timeout inside the endpoint's latency budget. Once a write reaches its commit or publish boundary, I either complete it reliably or hand it to durable work rather than abandoning it halfway. An OperationCanceledException is expected when the relevant token was cancelled, so telemetry records it separately from faults and avoids noisy error alerts. Background work must not retain the request token or HttpContext; it copies the required data and uses the worker's shutdown token instead.

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

Creating a new token and ignoring the request token
Passing the token only to the first method
Assuming cancellation rolls back external side effects
Logging every cancellation as an error
Swallowing OperationCanceledException without understanding the cause

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

Details

Does not know cancellation is cooperative
Confuses timeout with cancellation
Ignores downstream EF/HTTP calls
Treats cancelled writes as safely rolled back

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.

How is timeout different from cancellation?
What if cancellation happens after a side effect?
How would you pass cancellation into EF Core?
Should request cancellation be logged as an error?

Continue the section

Next in ASP.NET Core Framework: Middleware vs Filters

Step 9 of 26

Middleware vs filters in ASP.NET Core

How would you use CancellationToken in an ASP.NET Core API endpoint?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

How would you use CancellationToken in an ASP.NET Core API endpoint?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section