Why pass CancellationToken into EF Core calls?

So abandoned requests can stop database work when possible.

A teammate wants to hide record inside a convenient helper. What should you check first?

Whether the helper makes ownership, inputs, failures, and tests easier to review.

Whether it reduces the number of files regardless of behavior.

Whether it removes the need for the lesson checklist.

Whether it can skip the production signals for this course.

Which artifact best proves this .NET APIs lesson is ready for review?

A repeatable check tied to nullable reference type and OpenAPI response review.

A note that says the happy path was manually clicked once.

A screenshot with no command, test, or failure-mode context.

A broad refactor that avoids the specific lesson outcome.

Basic foundation: a teammate says the happy path works, but "Records and nullable references" is still implicit. What should you ask for before merging?

A small contract, test, or review artifact that proves records and nullable references under a realistic failure case.

Skip compiler, OpenAPI, SQL, or host evidence until the capstone.

Hide the decision inside framework defaults so reviewers have less to read.

Treat production behavior as separate from the lesson implementation.

A reviewer has five minutes to evaluate this basic .NET APIs slice. Which evidence is strongest?

A focused artifact for project shape and dependency direction plus a repeatable test, log, OpenAPI diff, or deployment check.

A passing build with no note about contracts, query shape, or operations.

A screenshot of Swagger without checking response or failure cases.

A broad rewrite that does not map to the stage milestone.

Learn / .NET API Engineering Path

Modern C# API Foundations

Use records, nullable references, async methods, and options to establish reliable service contracts.

Course: .NET API Engineering Path. Level: Advanced. Topic: Typed backend.

Stage: basic - Basic foundation - C# and ASP.NET Core service contracts. Start with language and host fundamentals that make API contracts explicit before any framework shortcuts.

Outcomes

Model request shapes with records.
Propagate cancellation tokens.
Validate options at startup.

Concepts

record
nullable reference type
async Task
options pattern

Concept flow

Show how c# and asp.net core service contracts moves from trigger to implementation outcome in .NET APIs.

Request DTO
Endpoint
Application service
Options
Logger

Session flow

Model record (concept, 9 min) — Name the decisions behind record before writing code.
- Model request shapes with records.
- Explain where record belongs in order management API.
Build the vertical slice (walkthrough, 15 min) — Implement the smallest useful slice in Orders/CreateOrder.cs.
- Propagate cancellation tokens.
- Connect nullable reference type to a working example.
Verify and harden (exercise, 10 min) — Thread CancellationToken through a service method.
- Validate options at startup.
- Record one risk or follow-up before moving on.

Code example

C# in Orders/CreateOrder.cs.

public sealed record CreateOrderRequest(Guid CustomerId, int TotalCents)
      {
          public bool IsValid => CustomerId != Guid.Empty && TotalCents > 0;
      }
      
      public interface IOrders
      {
          Task<OrderDto?> FindAsync(Guid id, CancellationToken ct);
      }

Walkthrough examples

Modern C# API Foundations in a order management API — A team is extending a production-grade ASP.NET Core order API and needs this lesson's pattern to be clear enough for review, testing, and future maintenance.
- File: Orders/CreateOrder.cs
- File: src/Orders.Application/modern-csharp-api-foundations.cs
- File: tests/Orders.Api.Tests/modern-csharp-api-foundations.Tests.cs
- File: docs/dotnet-advanced/modern-csharp-api-foundations.md
- Start from the provided C# snippet and make the intent visible in names and boundaries.
- Apply the checklist item "No nullable warnings ignored" before adding extra behavior.
- Write down how the implementation changes when nullable reference type fails or becomes slow.

Practice

Enable nullable reference types.
Create one request record.
Thread CancellationToken through a service method.

Checklist

No nullable warnings ignored
Records represent command data
Async calls accept cancellation
Options are validated

Quiz prompts

Why pass CancellationToken into EF Core calls? — Cancellation helps release resources when callers disconnect or shutdown begins.
A teammate wants to hide record inside a convenient helper. What should you check first? — Place record at the boundary that keeps order management API behavior explicit, testable, and reviewable.
Which artifact best proves this .NET APIs lesson is ready for review? — Production-ready learning needs evidence: a test, trace, command, screenshot, or log that catches the risk again.
Basic foundation: a teammate says the happy path works, but "Records and nullable references" is still implicit. What should you ask for before merging? — Records and nullable references belongs in the basic stage only when the decision is visible, testable, and tied to a realistic failure mode.
A reviewer has five minutes to evaluate this basic .NET APIs slice. Which evidence is strongest? — Create the basic order API contract layer: request records, validated options, cancellation-aware service interfaces, and a short note explaining which invariants belong at this layer.

Flashcards

Basic foundation: what decision does "Records and nullable references" force you to make? Use immutable request shapes and compiler feedback to remove ambiguous input handling. Evidence prompt: Convert one mutable request class into a record and resolve every nullable warning intentionally.
Basic foundation: what decision does "Async boundaries, options, and cancellation" force you to make? Thread cancellation and validated configuration through the first service boundary. Evidence prompt: Make one service method cancellation-aware and validate its options at startup.
Basic foundation: what decision does "Project shape and dependency direction" force you to make? Keep API, application, and infrastructure references pointed in one reviewable direction from the first commit. Evidence prompt: Draw the project references and move one misplaced framework concern back to the API edge.
In .NET APIs, what should you remember about record? record matters here because it supports "Model request shapes with records.".
In .NET APIs, what should you remember about nullable reference type? nullable reference type matters here because it supports "Propagate cancellation tokens.".
In .NET APIs, what should you remember about async Task? async Task matters here because it supports "Validate options at startup.".
In .NET APIs, what should you remember about options pattern? options pattern matters here because it supports "Model request shapes with records.".

Labs

Ship a modern c# api foundations slice — Extend a production-grade ASP.NET Core order API with a small but reviewable feature that proves the lesson's architecture in code.
- Create the basic order API contract layer: request records, validated options, cancellation-aware service interfaces, and a short note explaining which invariants belong at this layer.
- Convert one mutable request class into a record and resolve every nullable warning intentionally.
- Make one service method cancellation-aware and validate its options at startup.
- Draw the project references and move one misplaced framework concern back to the API edge.
- Enable nullable reference types.
- Create one request record.
- The lab demonstrates the basic foundation outcome without skipping earlier contract evidence.
- Each subtopic has a concrete artifact: Records and nullable references, Async boundaries, options, and cancellation, Project shape and dependency direction.
- The review notes explain how this level changes ownership, verification, or operational risk.

Challenge

Review-ready modern c# api foundations (Core) — Create the basic order API contract layer: request records, validated options, cancellation-aware service interfaces, and a short note explaining which invariants belong at this layer.
- All checklist items are either implemented or documented with a reason.
- The change can be understood from Orders/CreateOrder.cs plus one short note.
- The concept diagram names ownership, failure handling, and verification points.
- A teammate could run the verification steps without asking for hidden context.

Canonical lesson URL