Async calls, cancellation and provider limits

Separate an async contract from the provider’s actual I/O capability

EF exposes Task-based query and save APIs so callers can compose asynchronous operations and pass cancellation. Whether native I/O actually proceeds asynchronously depends on the database provider. Microsoft.Data.Sqlite documents that its asynchronous ADO.NET methods execute synchronously because SQLite does not support asynchronous I/O in that form. The course still uses the standard EF async shape for consistency and cancellation wiring, while explicitly refusing to call it a SQLite nonblocking-performance demonstration. That distinction matters when a desktop sample is later moved to a responsive interface or compared with a network database provider.

Observe a pre-cancelled EF query deterministically

The external program first creates a real row and completes that save. It then cancels the operation source before passing its token to ToListAsync. The expected OperationCanceledException establishes the selected pre-cancellation path without a racing timer or a slow public database. A fresh context verifies that the earlier stored row remains. That verification does not mean cancellation rolled back the previous save; it deliberately demonstrates that the committed row still exists. The test makes no claim about interrupting a native statement halfway through execution or about the number of commands that every provider might start before observing a token.

using System;
using System.Linq;
using System.Collections.Generic;
using System.Threading;
using System.Threading.Tasks;
using Microsoft.Data.Sqlite;
using Microsoft.EntityFrameworkCore;

await using var connection = new SqliteConnection("Data Source=:memory:;Foreign Keys=True");
await connection.OpenAsync();
var options = new DbContextOptionsBuilder<LabDb>().UseSqlite(connection).Options;
await using var db = new LabDb(options); await db.Database.EnsureCreatedAsync(); db.Items.Add(new Item { Name = "rune" }); await db.SaveChangesAsync();
using var owner = new CancellationTokenSource(); owner.Cancel(); bool cancelled = false;
try { await db.Items.AsNoTracking().ToListAsync(owner.Token); }
catch (OperationCanceledException) { cancelled = true; }
Check(cancelled, "pre-cancelled EF query");
await using var verify = new LabDb(options); Check(await verify.Items.CountAsync() == 1, "stored row unchanged");
Console.WriteLine("cancelled"); Console.WriteLine("rows:1");

static void Check(bool condition, string name) { if (!condition) throw new InvalidOperationException("CHECK: " + name); }

Keep the token guard’s evidence narrow

The .NET9 companion creates an already cancelled CancellationTokenSource, then calls ThrowIfCancellationRequested before its supplied completion line. The catch prints cancelled. No EF query, database connection or provider is involved. This is a useful control-flow baseline because it proves what the token guard means independently of transport or storage. It does not establish that a provider supports mid-command cancellation or that an async method necessarily yielded execution. Preserve those narrower claims when a test double completes synchronously: a deterministic guard test and a provider integration test answer related but different questions.

An outstanding operation still owns its context

Await each EF operation before starting another on the same DbContext. Cancellation does not make concurrent reuse safe, and abandoning a Task without observing its completion does not release the context lifetime cleanly. An operation owner should pass its token through query and save calls that belong to that operation, while cleanup and transaction reconciliation need their own policies. Disposing a CancellationTokenSource does not request cancellation. A cancelled wait also is not proof that a remote database mutation never committed, especially with a network provider and an uncertain result. Classify the evidence before deciding to retry or report success.

Practice: compare normal completion with pre-cancellation

Use a fresh context for a normal uncancelled query and verify its materialized result, then keep the existing already-cancelled case as an independent assertion. Do not use a fixed sleep to try to catch SQLite in the middle of a statement and present that race as reliable coverage. If production needs a network provider’s cancellation behavior, design a controlled integration test in that environment with a documented command and deadline. Record whether the evidence concerns caller cancellation, provider interruption or committed state, and preserve the distinction in failure messages.

• Hint: a pre-cancelled token is a deterministic case, not a mid-I/O timing test.
• Hint: do not issue another operation on the same context before the first completes.

Practice: model cancellation without losing result categories

Extend the BCL practice to return named Completed, Cancelled and InvalidInput outcomes for separate supplied scenarios. Keep invalid data validation independent from the token’s state so a test can identify which contract was exercised. Then use an explicitly coordinated asynchronous operation to request cancellation between two stages without relying on elapsed time. That model still has no database and cannot determine rollback. Its purpose is to make ownership and error classification clear before attaching a provider adapter. Verify that every started task is observed and that an already produced result is not mislabeled as an abandoned operation.

• Hint: cancelled and invalid are separate outcomes even when both stop useful work.
• Hint: completion signals make stage ordering clearer than arbitrary delays.

Review cancellation guarantees at the intended provider boundary

The actual SQLite project and the BCL lab both report their controlled cancelled outcomes, but only the external project crosses EF’s query boundary. Neither proves responsive native SQLite I/O or universal server-side cancellation. A useful production review identifies the caller token, context owner, awaited operations, timeout policy and any reconciliation needed after uncertain writes. Repeat relevant integration checks against the provider that will run in production. Keeping those limits explicit prevents a Task-shaped API from being mistaken for a performance or rollback guarantee that its implementation and storage engine do not promise.