
Today I’m back for a smaller post, on a topic that has already some amount of posts about, but I think is not spread enough and it’s not being used as much as it could, and probably should - using cancellation tokens with ASP.NET Core MVC actions (video walk-through at the end of the post).
If you want to follow along with the code, it’s here.
A scenario
Imagine we create a Web API to power our frontend. We have a search box with autocomplete, have the usual debounce logic to avoid a request on every keystroke, but even with this logic in place, sometimes it takes longer for the user to complete the train of thought. When this happens, the client side application makes a new request and disregards the previous ones. On the server side, if we’re not expecting this to happen, the application will just complete the requested operation and issue a response as if nothing happened, having completed a workload for nothing, misusing the server’s resources.
A solution
Fortunately, there’s a stupid simple solution for this problem. On our controller’s action methods, we can receive a CancellationToken
instance and pass it around our asynchronous methods. When the client cancels a request, this token will be signaled and our methods are notified and can act accordingly.
Some samples
For the samples, I’m making something simpler then the autocomplete scenario I talked above, but I think it’s more than enough to take the point across.
|
|
So here we have a stupid simple action, that has no client supplied arguments, only a CancellationToken
. This CancellationToken
is injected by the framework and will be signaled for cancellation by the framework. A case in which it is signaled - when the client cancels the request. In the demo code I’m just invoking an external endpoint that will take 5 seconds to complete, passing the token to the GetAsync
method. I’m wrapping it all up in try catch and expecting a TaskCanceledException
, as it’s the one thrown when the operation is canceled due to cancellation token being signaled.
Below I added a gif with a quick show of a request being canceled.

Here’s another quick sample:
|
|
In this case, besides passing the CancellationToken
along to other asynchronous methods - in this case a Task.Delay
but the result of the cancellation is similar to the HttpClient.GetAsync
- I’m checking the token to see if it was signaled for cancellation. So, imagine the Task.Delay
method didn’t accept a CancellationToken
as an argument, on the next loop iteration the code would check for a cancellation request and would throw an exception (in this case an OperationCanceledException
).
This may be useful in scenarios we’re not doing async work that nevertheless takes a while to complete and would benefit from being cancellable along the way.
Video walk-through
If you’re more in a mood for video walk-through rather the reading, be my guest :)
Hope this was useful. Thanks for reading/watching, cyaz!