Error: The Delegate RequestDelegate Does Not Take X Arguments – Experiences with Minimal APIs

If you've spent any time building .NET minimal APIs and tried to improve your OpenAPI documentation with explicit return types, you've likely encountered this frustrating compiler error:

Delegate 'RequestDelegate' does not take X arguments

This error stopped me mid-flow during a recent project, and I want to share what causes it and how to fix it properly.

The Setup

Minimal APIs in ASP.NET Core are elegant. You define endpoints with concise lambda expressions, and the framework handles routing, model binding, and response serialization. A simple endpoint might look like this:

app.MapGet("/api/products/{id}", (int id, ProductDbContext db) =>
{
    var product = db.Products.Find(id);
    return product is not null
        ? Results.Ok(product)
        : Results.NotFound();
});

This works perfectly. The problem begins when you try to be more explicit about your return types — something that's actually encouraged for better OpenAPI documentation.

The Problem: TypedResults and OpenAPI

When you want your Swagger or OpenAPI spec to accurately reflect what your endpoint can return, you might reach for TypedResults instead of Results. The TypedResults class returns concrete types like Ok<T> or NotFound, which give the OpenAPI generator richer metadata.

So you refactor your endpoint:

app.MapGet("/api/products/{id}", (int id, ProductDbContext db) =>
{
    var product = db.Products.Find(id);
    return product is not null
        ? TypedResults.Ok(product)
        : TypedResults.NotFound();
});

And suddenly, the compiler throws:

Delegate 'RequestDelegate' does not take 2 arguments

The error is confusing because you haven't changed the logic — only the return type helpers. What's happening under the hood is that the compiler can no longer infer a single return type from the lambda. TypedResults.Ok<Product> and TypedResults.NotFound are different types, and without a common base the compiler falls back to trying to match RequestDelegate, which only accepts HttpContext.

The Fix: Use Results<T1, T2>

The solution is to explicitly declare the return type using the generic Results<T1, T2> wrapper. This type tells both the compiler and the OpenAPI generator exactly which responses are possible:

app.MapGet("/api/products/{id}",
    Results<Ok<Product>, NotFound> (int id, ProductDbContext db) =>
{
    var product = db.Products.Find(id);
    return product is not null
        ? TypedResults.Ok(product)
        : TypedResults.NotFound();
});

By specifying Results<Ok<Product>, NotFound> as the return type of the lambda, you achieve two things:

1. The compiler is satisfied — it now knows the lambda returns a Results<Ok<Product>, NotFound>, which has implicit conversions from both Ok<Product> and NotFound.
2. OpenAPI documentation improves — the framework generates accurate response schemas showing both 200 OK with a Product body and 404 Not Found.

Scaling to More Response Types

The Results generic type supports up to six type parameters, so you can handle complex endpoints cleanly:

app.MapPost("/api/products",
    Results<Created<Product>, ValidationProblem, Conflict> 
    (CreateProductRequest request, ProductDbContext db) =>
{
    // Validation, conflict checks, creation logic...
});

This pattern keeps your minimal API endpoints concise while providing the compiler and documentation tooling with everything they need.

A Note on AI-Assisted Development

Interestingly, I first encountered this error while using GitHub Copilot to scaffold endpoint code. Copilot suggested TypedResults for better documentation — a good instinct — but didn't wrap the return type in Results<T1, T2>. It's a reminder that AI coding assistants are powerful accelerators, but understanding the underlying framework behaviour is still essential. The suggestion was 90% correct, which in programming means it didn't compile.

Key Takeaways

• Results (static class) works fine for basic endpoints but provides limited OpenAPI metadata.
• TypedResults (static class) provides rich return types but requires explicit lambda return type declarations.
• Results<T1, T2, ...> (generic type) is the bridge — it satisfies the compiler and enriches your API documentation.
• Always verify AI-generated code against the framework's type system, especially when multiple return types are involved.

Minimal APIs are a fantastic addition to ASP.NET Core, and with the Results<T1, T2> pattern, you get the best of both worlds: clean code and comprehensive OpenAPI specs.