Why would you pass CancellationToken into EF Core queries from an ASP.NET Core endpoint?

I use cancellation as part of database-pressure control, not as a correctness guarantee. Reads are usually safe to abandon; writes need transaction and idempotency thinking because cancellation during SaveChangesAsync can leave uncertainty about what happened. I still add query timeouts, use projections, avoid N+1 patterns, and monitor connection pool pressure. Cancellation reduces waste, but it does not replace proper data-access design. In production I would bound the work explicitly and observe it: active operations, queue length, cancellation rate, dependency latency, and failure rate. I would avoid designs where every request can create unlimited work, because that turns a small dependency slowdown into a process-wide outage.