Operation canceled: Microsoft Graph .NET SDK CancellationToken propagation

Short answer

Cancelling the token reliably aborts the in-flight HTTP request on the client — the SDK v5 (Kiota-generated) forwards your CancellationToken down to HttpClient.SendAsync, and you get an OperationCanceledException promptly. What it does not do is signal Exchange Online, Entra ID, or any other Microsoft 365 workload to stop work already dispatched server-side. There is no documented mechanism for that, so treat client-side cancellation as a way to free client resources and stop waiting — not as a backend load-reduction tool.

What actually happens on cancel

1. The token fires and HttpClient tears down the connection (TCP/TLS close, or an HTTP/2 stream reset).
2. Your code observes OperationCanceledException (or its subclass TaskCanceledException).
3. The server sees the connection drop. For fast read operations the work is usually already done or gets discarded; for long-running or queued backend operations, processing may continue to completion regardless.

Two practical consequences follow. First, do not assume cancelling rolls anything back: a non-idempotent POST or PATCH may already have taken effect server-side. Second, if you genuinely need to stop server-side work, use the operation-specific API where one exists — for example deleting a long-running operation resource or cancelling an async job through its dedicated endpoint — rather than the token.

Distinguishing your cancellation from the 100-second timeout

The default HttpClient timeout (~100 seconds) also surfaces as TaskCanceledException, which looks identical to caller-initiated cancellation. Check the token to tell them apart:

var cts = new CancellationTokenSource(TimeSpan.FromSeconds(1));
try
{
    var users = await graphClient.Users.GetAsync(cancellationToken: cts.Token);
}
catch (OperationCanceledException) when (cts.IsCancellationRequested)
{
    // Your token fired — client-side abort.
}
catch (OperationCanceledException)
{
    // Token was NOT cancelled — likely the HttpClient timeout.
}

If cancellation seems not to work at all, look for custom HttpClient handlers, retry middleware, or buffered response reads that delay observing the token until the next await point.

How to verify the behavior yourself

• Client abort: run a slow query (large $top or unfiltered search), cancel after ~1 second, and confirm the exception arrives in ~1 second with IsCancellationRequested == true — not at the ~100-second timeout mark.
• Connection teardown: capture a trace with Fiddler or Wireshark and confirm the client closes the connection immediately on cancel.
• Backend continuation: start a cancellable long-running operation, cancel client-side, then poll the operation or resource state to see whether server-side processing continued.

Caveats

Backend propagation is not contractually documented by Microsoft and can vary per workload (Exchange, SharePoint, Entra) and change over time — the statements above describe well-established client behavior plus a likely explanation for the server side, not a guarantee. This guidance also assumes SDK v5 (Kiota); the v4 request pipeline differs, so don't apply it across major versions. For anything load-critical, confirm current semantics against the SDK and Kiota repositories before relying on them.