Using I(Async)ResultFilter with TypedResults

[TDroogh]

Hi community,

I'm using ASP.NET core version 10.0.7 with API contrllers.
We're currently using the IActionResult interface as return type on our controller actions and would like to migrate to TypedResults, as this provides strong typing for responses AND automatically documents the response types in our OpenAPI specifications.

With the old ActionResults i was able to create an IAsyncResultFilter and inspect the type of the result. This can be done quite easily by using pattern checking on the type ObjectResult, or other derived types such as NotFoundResult. However, for the TypedResult classes, the result type is HttpActionResult, which is an ASP.NET core internal type. So for now, i don't have a way to access the (typed) result using this filter, other than using reflection to access the Result property of the HttpActionResult, but that doesn't feel like the way to do it.

I could not find any documentation on other filters that are able to access the (typed) result, so am i missing something, or should the HttpActionResult type be public instead of internal?

[MostafaChronic]

This is a brilliant architectural question that highlights a known gap in the transition from traditional API Controllers (IActionResult) to the newer TypedResults ecosystem (which was originally designed with Minimal APIs in mind).

You hit the nail on the head: HttpActionResult is indeed an internal wrapper used by the framework when TypedResults are returned from standard Controller Actions. This makes traditional pattern matching in an IAsyncResultFilter highly problematic without resorting to fragile reflection.

Here is a breakdown of why this happens, why making HttpActionResult public isn't the ideal fix, and the clean, future-proof ways to handle this in ASP.NET Core 10.

---

Why is this happening?

When you return a TypedResult (like Results.Ok(data) or TypedResults.NotFound()), you are returning a concrete type that implements IResult (from Microsoft.AspNetCore.Http).

• Minimal APIs natively understand IResult and execute it directly.
• API Controllers, however, historically rely on IActionResult. To bridge this gap, the MVC engine wraps your IResult inside an internal HttpActionResult wrapper so the controller infrastructure can process it.

Because it's internal, your result filter sees the wrapper instead of the underlying IResult type, hiding the strong typing you are trying to leverage.

---

The Solutions

Instead of fighting the internal wrapper in an IAsyncResultFilter, you should shift to extensibility points that natively understand IResult or bypass the MVC wrapper entirely.

Option 1: Use IEndpointFilter (The Recommended Approach)

Starting in recent versions of ASP.NET Core, Endpoint Filters are supported on API Controllers, not just Minimal APIs. Endpoint filters intercept the execution at the routing level before MVC wraps the result, giving you direct, strongly-typed access to the IResult.

Here is how you can inspect the TypedResult:

public class TypedResultInspectionFilter : IEndpointFilter
{
    public async ValueTask<object?> InvokeAsync(EndpointFilterInvocationContext context, EndpointFilterDelegate next)
        {
        var result = await next(context);

        // At this stage, 'result' is the raw IResult (e.g., Ok<MyDto>, NotFound)
        // before MVC wraps it into HttpActionResult
        if (result is Microsoft.AspNetCore.Http.HttpResults.Ok<MyDto> okResult)
        {
            var value = okResult.Value; // Strongly typed data!
            // Do your logic here
        }
        else if (result is Microsoft.AspNetCore.Http.HttpResults.NotFound notFoundResult)
        {
            // Handle NotFound
        }

        return result;
    }
}

Registration:
You can apply it globally to your controllers or on specific actions using the AddEndpointFilter extension:

builder.Services.AddControllers(options =>
{
    // Note: Standard MVC filter collections don't accept IEndpointFilter, 
    // so you apply it to mapped endpoints:
});

// For global application across mapped controller endpoints:
app.MapControllers().AddEndpointFilter<TypedResultInspectionFilter>();

---

Option 2: Duck-Typing via IResult Unwrapping (If you must stay in IAsyncResultFilter)

If your architecture heavily relies on existing IAsyncResultFilter pipelines and you cannot switch to Endpoint Filters, you can safely unwrap the internal type without reflection by looking for the underlying IResult.

While HttpActionResult is internal, the wrapper itself implements features to expose the inner IResult. You can write a helper to extract it safely:

public class MyResultFilter : IAsyncResultFilter
{
    public async Task OnResultExecutionAsync(ResultExecutingContext context, ResultExecutionDelegate next)
    {
        var result = context.Result;

        // Use pattern matching to find if it encapsulates an IResult
        // In .NET 10, the internal wrapper exposes the inner IResult via structural interfaces
        if (result is var mvcResult && mvcResult.GetType().GetProperty("Result")?.GetValue(mvcResult) is IResult innerResult)
        {
            // Now you can inspect the TypedResult directly
            if (innerResult is Microsoft.AspNetCore.Http.HttpResults.Ok<MyDto> okResult)
            {
                var data = okResult.Value;
            }
        }

        await next();
    }
}

⚠️ Note: While this avoids hardcoded string reflection for method invocation, it still relies on property inspection. This is why Option 1 (Endpoint Filters) is the architecturally superior choice moving forward with .NET 10.

---

Summary for your OpenAPI + Strong Typing Goals

You are on the right track! Moving to TypedResults is excellent for automated OpenAPI documentation via Microsoft.AspNetCore.OpenApi (the new built-in OpenAPI support replacing Swashbuckle in newer .NET versions).

To keep your pipeline clean, embrace Endpoint Filters (IEndpointFilter). They are the native tool for inspecting IResult/TypedResults and will completely eliminate the internal wrapper visibility issue you are facing.