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.

[rodri-oliveira-dev]

I think the key here is where each filter runs in the MVC pipeline.

Looking at the current ASP.NET Core implementation, HttpActionResult is not really the result produced by the controller. It is an adapter introduced by MVC afterwards.

The relevant flow in ActionMethodExecutor is essentially:

var result = await filterDelegate(context);

return ConvertToActionResult(
    mapper,
    result,
    returnType);

and then ActionResultTypeMapper does:

if (value is IResult httpResult)
{
    return new HttpActionResult(httpResult);
}

So by the time an IAsyncResultFilter runs, the original IResult has already crossed the MVC boundary and has been wrapped in the internal HttpActionResult.

That also explains why reflection works but feels wrong: there currently isn't a public MVC abstraction on ResultExecutingContext.Result that exposes the inner IResult.

For this particular use case, I would therefore move the inspection one level earlier and use an IEndpointFilter.

Controller endpoints support endpoint filters, so this can also be applied to MapControllers():

app.MapControllers()
    .AddEndpointFilter<TypedResultFilter>();

For example:

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

        var httpResult = result switch
        {
            INestedHttpResult nested => nested.Result,
            IResult direct => direct,
            _ => null
        };

        if (httpResult is IStatusCodeHttpResult statusResult)
        {
            var statusCode = statusResult.StatusCode;

            // Inspect status code here.
        }

        if (httpResult is IValueHttpResult valueResult)
        {
            var value = valueResult.Value;

            // Inspect response value here.
        }

        return result;
    }
}

I would prefer using the public result contracts such as IStatusCodeHttpResult, IValueHttpResult, and INestedHttpResult instead of pattern matching every concrete TypedResults implementation.

The INestedHttpResult part is especially useful if the controller returns a typed union such as:

Results<Ok<MyResponse>, NotFound>

because the union itself contains the actual IResult.

If you need type-specific behavior, you can of course still inspect the concrete result:

if (httpResult is Ok<MyResponse> ok)
{
    var response = ok.Value;
}

Regarding making HttpActionResult public: I am not sure that would be the best abstraction to expose.

HttpActionResult is essentially an MVC-to-IResult adapter. Making application code depend on it would expose an implementation detail of the integration between the two result models.

What I think would be more useful, if MVC result filters are expected to support this scenario, would be a public abstraction that allows an IResult to be obtained from an IActionResult without depending on the concrete adapter.

But with the APIs available today, if the purpose of the filter is to inspect a TypedResult, I would consider IEndpointFilter the cleaner boundary. It sees the result before MVC converts it to IActionResult, avoids reflection, and lets the code depend only on the public HTTP result interfaces.

So I don't think you're missing a way to unwrap HttpActionResult from an IAsyncResultFilter: at that point in the pipeline the public abstraction for doing so simply isn't there.

[sireskandari]

I think the important distinction here is where the result is being inspected in the pipeline.

When a controller returns a TypedResult, the original object implements IResult, but MVC converts/wraps that result before IAsyncResultFilter runs. At that point ResultExecutingContext.Result is already the MVC-side adapter (HttpActionResult), which is why the actual typed result is no longer exposed through a public API.

So I would avoid depending on HttpActionResult or reflecting its internal Result property.

For this use case, an endpoint filter seems like a cleaner boundary because controller actions can also have endpoint filters applied:

app.MapControllers()
    .AddEndpointFilter(async (context, next) =>
    {
        var result = await next(context);

        if (result is IStatusCodeHttpResult statusResult)
        {
            var statusCode = statusResult.StatusCode;
            // inspect status
        }

        if (result is IValueHttpResult valueResult)
        {
            var value = valueResult.Value;
            // inspect response value
        }

        return result;
    });

If you're returning a typed union such as:

Results<Ok<MyResponse>, NotFound>

I'd also account for INestedHttpResult:

var result = await next(context);

var httpResult = result switch
{
    INestedHttpResult nested => nested.Result,
    IResult direct => direct,
    _ => null
};

if (httpResult is IStatusCodeHttpResult status)
{
    Console.WriteLine(status.StatusCode);
}

if (httpResult is IValueHttpResult value)
{
    Console.WriteLine(value.Value);
}

return result;

That has a couple of advantages over checking concrete types such as Ok<MyDto>:

• it stays on public ASP.NET Core interfaces;
• it supports more TypedResults without adding a case for each result class;
• it avoids coupling application code to the internal MVC adapter;
• it still lets you pattern-match the concrete result when you actually need type-specific behavior.

So I don't think you're overlooking a public way to unwrap HttpActionResult inside IAsyncResultFilter. By the time that filter runs, MVC has already performed the conversion.

If the purpose of the filter is specifically to inspect the original TypedResult, I'd move that part of the logic to an IEndpointFilter and keep MVC result filters only for logic that actually needs the IActionResult abstraction.

[Alfonso-13]

You're not missing anything: HttpActionResult is internal and there's no
built-in filter that exposes the typed IResult for controller actions.

There is a supported extension point though. The conversion from an action's
return value to an IActionResult goes through IActionResultTypeMapper, which is
a public service you can replace. That lets you wrap the IResult in your own
public type instead of HttpActionResult:

public sealed class TypedHttpActionResult(IResult result) : ActionResult
{
    public IResult Result { get; } = result;

    public override Task ExecuteResultAsync(ActionContext context)
        => Result.ExecuteAsync(context.HttpContext);
}

public sealed class TypedResultsActionResultTypeMapper : IActionResultTypeMapper
{
    public Type GetResultDataType(Type returnType)
    {
        if (returnType.IsGenericType &&
            returnType.GetGenericTypeDefinition() == typeof(ActionResult<>))
        {
            return returnType.GetGenericArguments()[0];
        }

        return returnType;
    }

    public IActionResult Convert(object? value, Type returnType) => value switch
    {
        IConvertToActionResult converter => converter.Convert(),
        IResult httpResult => new TypedHttpActionResult(httpResult),
        _ => new ObjectResult(value) { DeclaredType = returnType }
    };
}

builder.Services.AddSingleton<IActionResultTypeMapper, TypedResultsActionResultTypeMapper>();

Then your result filter can pattern match without reflection. The IResult
metadata interfaces (IStatusCodeHttpResult, IValueHttpResult,
INestedHttpResult) are public, so you don't need to know the concrete types:

public class InspectResultFilter : IAsyncResultFilter
{
    public async Task OnResultExecutionAsync(
        ResultExecutingContext context, ResultExecutionDelegate next)
    {
        if (context.Result is TypedHttpActionResult { Result: var result })
        {
            // Results<Ok<T>, NotFound> wraps the actual result
            if (result is INestedHttpResult nested)
            {
                result = nested.Result;
            }

            var statusCode = (result as IStatusCodeHttpResult)?.StatusCode;
            var value = (result as IValueHttpResult)?.Value;

            // inspect / log / replace context.Result here
        }

        await next();
    }
}

If you'd rather not replace a framework service, the alternative is opening an
API proposal on this repo to make HttpActionResult (or at least its Result
property) public. Your use case is a reasonable argument for it, since
TypedResults are now the recommended approach for OpenAPI metadata.

If this solves it, feel free to mark it as the answer.