Instead of globally increasing the max request body size in Kestrel, you can now set a max body size per endpoint where necessary like so:

public override void Configure()
{
    Post("/file-upload");
    AllowFileUploads();
    MaxRequestBodySize(50 * 1024 * 1024);
}

You can now specify a custom response builder function when doing .UseProblemDetails() as shown below in case you have a special requirement to use a certain shape for one or more of your endpoints while the rest of the endpoints use the standard response.

app.UseFastEndpoints(
       c => c.Errors.UseProblemDetails(
           p =>
           {
               p.ResponseBuilder = (failures, ctx, statusCode) =>
                                   {
                                       if (ctx.Request.Path.StartsWithSegments("/group-name"))
                                       {
                                           // return any shape you want to be serialized
                                           return new
                                           {
                                               Errors = failures
                                           };
                                       }

                                       // anything else will use the standard problem details.
                                       return new ProblemDetails(failures, ctx.Request.Path, ctx.TraceIdentifier, statusCode);
                                   };
           }))

The FastEndpoints.ProblemDetails.Detail property has been unused until now. It will now by default be populated according to the following DetailTransformer logic, which you can customize if needed. The transformer can also be set to null in case you'd like to go back to the previous behavior.

app.UseFastEndpoints(
       c => c.Errors.UseProblemDetails(
           p =>
           {
               p.DetailTransformer = pd => pd.Errors.Count() == 1
                                               ? pd.Errors.First().Reason
                                               : null;
           }))

The default behavior is to populate the Detail property with the reason if there's only 1 error and not populate it at all in case there's more than 1 error.

It is now possible to register a particular open generic request binder such as the following:

class MyBinder<TRequest> : RequestBinder<TRequest> where TRequest : notnull 
{ 
    public override async ValueTask<TRequest> BindAsync(BinderContext ctx, CancellationToken ct) 
    { 
        var req = await base.BindAsync(ctx, ct); // run the default binding logic
 
        if (req is MyRequest r) 
            r.SomeValue = Guid.NewGuid().ToString(); // do whatever you like
 
        return req; 
    } 
} 

only for a certain group configuration, so that only endpoints of that group will have the above custom binder associated with them.

sealed class MyGroup : Group 
{ 
    public MyGroup() 
    { 
        Configure("/my-group", ep => ep.RequestBinder(typeof(MyBinder<>))); 
    } 
} 

With the built-in versioning, you could only have the endpoint version number either pre-fixed or post-fixed. You can now make the version appear anywhere in the route by using a route template. The template segment will be replaced by the actual version number instead of being prepended or appended.

sealed class MyEndpoint : EndpointWithoutRequest
{
    public override void Configure()
    {
        Get("/sales/{_version_}/my-endpoint");
        Version(1);
    }

    ...
}

This version placement strategy must be enabled at startup like so:

app.UseFastEndpoints(
       c =>
       {
           c.Versioning.RouteTemplate = "{_version_}";
       })

If this setting is enabled, it will take precedence over the default behavior of appending/prepending the version number to the route.

Endpoints can now be setup to execute a FeatureFlag for every Http request that comes in, which allows an endpoint to be conditionally available according to some evaluation logic.

To create a feature flag, implement the interface IFeatureFlag and simply return true from the IsEnabledAsync() handler method if the endpoint is to be accessible to that particular request.

sealed class BetaTestersOnly : IFeatureFlag 
{ 
    public async Task<bool> IsEnabledAsync(IEndpoint endpoint) 
    { 
        //use whatever mechanism/library you like to determine if this endpoint is enabled for the current request. 
        if (endpoint.HttpContext.Request.Headers.TryGetValue("x-beta-tester", out _)) 
            return true; // return true to enable 
 
        //this is optional. if you don't send anything, a 404 is sent automatically. 
        await endpoint.HttpContext.Response.SendErrorsAsync([new("featureDisabled", "You are not a beta tester!")]); 
 
        return false; // return false to disable 
    } 
}

Attach it to the endpoint like so:

sealed class BetaEndpoint : EndpointWithoutRequest<string>
{
    public override void Configure()
    {
        Get("beta");
        FeatureFlag<BetaTestersOnly>();
    }

    public override async Task HandleAsync(CancellationToken c)
    {
        await Send.OkAsync("this is the beta!");
    }
}

You can now decorate request DTO properties with [FromCookie] and matching cookies will be auto bound from incoming request cookies.

Until now, only the top level properties of a request DTO was being validated when using Data Annotation Attributes. This release adds support for recursively validating the whole object graph and generating errors for each that fails validation.

The SSE response implementation has been enhanced by making the Id property in StreamItem optional, adding an optional Retry property for client-side reconnection control, as well as introducing an extra StreamItem constructor overload for more flexibility. Additionally, the X-Accel-Buffering: no response header is now automatically sent to improve compatibility with reverse proxies like NGINX, ensuring streamed data is delivered without buffering. You can now do the following when doing multi-type data responses:

yield return new StreamItem("my-event", myData, 3000);

The SSE implementation now passes the ApplicationStopping cancellation token to your IAsyncEnumerable method. This means that streaming is cancelled at least when the application host is shutting down, and also when a user provided CancellationToken (if provided) triggers it.

public override async Task HandleAsync(CancellationToken ct)
{
    await Send.EventStreamAsync(GetMultiDataStream(ct), ct);

    async IAsyncEnumerable<StreamItem> GetMultiDataStream([EnumeratorCancellation] CancellationToken ct)
    {
        // Here ct is now your user provided CancellationToken combined with the ApplicationStopping CancellationToken.
        while (!ct.IsCancellationRequested)
        {
            await Task.Delay(1000, ct);

            yield return new StreamItem(Guid.NewGuid(), "your-event-type", 42);
        }
    }
}

If you need to do some async work in the global response modifier, you can now use the GlobalResponseModifierAsync variant.

Until now, you were meant to obtain an instance of the validation context via ValidationContext.Instance in the method itself. Starting this release, you are now able to obtain it either in the constructor or property initializers and cache it for later use.

The wrong variant (SecurityAlgorithms.HmacSha256Signature) was being used for creating symmetric JWTs by default. The default value has been changed to SecurityAlgorithms.HmacSha256. It's recommended to invalidate and regenerate new tokens if you've been using the default.

If for some reason, you'd like to keep using SecurityAlgorithms.HmacSha256Signature, you can set it yourself like so:

var token = JwtBearer.CreateToken(
    o =>
    {
        o.SigningKey = ...;
        o.SigningAlgorithm = SecurityAlgorithms.HmacSha256Signature;
    });

The testing httpclient extensions were ignoring user supplied custom header names such as the following:

[FromHeader("x-something")]

during the constructing of the http request message. It was instead using the DTO property name completely dismissing the custom header names.

The test helper methods were constructing the url/route of the endpoint being tested incorrectly if that endpoint belonged to a group and was configured with an empty route like so:

sealed class MyGroup : Group 
{ 
    public MyGroup() 
    { 
        Configure("my-group", ep => ep.AllowAnonymous()); 
    } 
} 
 
sealed class Request 
{ 
    [QueryParam] 
    public string Id { get; set; } 
} 
 
sealed class RootEndpoint : Endpoint<Request, string> 
{ 
    public override void Configure() 
    { 
        Get(string.Empty); 
        Group<MyGroup>(); 
    } 
 
    ...
}

When a base class has a virtual property that a derived class was overriding as shown below, Swagger generator was throwing an exception due an internal dictionary key duplication.

public abstract class BaseDto
{
    public virtual string Name { get; set; }
}

sealed class DerivedClass : BaseDto
{
    public override string Name { get; set; }
}

If a job was scheduled for the future, it would not get picked up for execution in case the app was restarted. It would only get executed upon queuing a new job. It has now been fixed by probing the storage provider once at startup to check if there's any jobs scheduled for the future.