The job queuing functionality has also been extracted out to a separate package FastEndpoints.JobQueues which can be used independently of the main FE library. No code changes are needed for existing FE projects.

You can now use the routeless test helpers such as .GETAsync<MyEndpoint>() with Aspire DistributedApplication testing like so:

[Fact]
public async Task Endpoint_Returns_Ok_Response()
{
    // Arrange
    var ct = TestContext.Current.CancellationToken;
    var appHost = await DistributedApplicationTestingBuilder.CreateAsync<Projects.AspireApp_AppHost>(ct);
    await using var app = await appHost.BuildAsync(ct).WaitAsync(_defaultTimeout, ct);
    await app.StartAsync(ct).WaitAsync(_defaultTimeout, ct);
    await app.ResourceNotifications.WaitForResourceHealthyAsync("apiservice", ct).WaitAsync(_defaultTimeout, ct);

    // Act
    var httpClient = app.CreateHttpClient("apiservice");
    var (response, _) = await httpClient.GETAsync<HelloEndpoint, EmptyResponse>();

    // Assert
    Assert.Equal(HttpStatusCode.OK, response.StatusCode);
}

An opt-in library that eliminates boilerplate health check wiring for apps running behind orchestrators such as Kubernetes/.NET Aspire. You can now use the following convenient extension method and it's overloads:

// Defaults: 
// - /health/live (liveness)
// - /health/ready (readiness)
builder.Services.AddServiceHealthChecks();

// Custom paths
builder.Services.AddServiceHealthChecks(
    configureOptions: opts =>
    {
        opts.LivePath = "/alive";
        opts.ReadyPath = "/ready";
    });

// Add custom health checks
builder.Services.AddServiceHealthChecks(
    configureChecks: hc =>
    {
        hc.AddNpgSql(connectionString, name: "postgres");
        hc.AddRedis("localhost:6379", name: "redis");
    });

Liveness returns 200 if process is alive (no dependency checks). Readiness runs all registered health checks and returns aggregate status with optional JSON response.

In a similar fashion to the previously released Test Event Receivers feature, you can now use Test Command Receivers to verify that a certain command execution was initiated by an endpoint or service without having to register fake command handlers.

Typically, you'd unit test the command/handlers in isolation to verify the business logic in those handlers and use the "Test Event/Command Receivers" to validate that certain entrypoints in your application actually do trigger/issue particular commands and events.

All FastEndpoints assemblies are now strong-name-signed. This only matters if your project is utilizing assembly signing. Signed projects will no longer show warnings about FastEndpoints not being signed.

SSE streams are now flushed after each write as opposed to after every batch. This eliminates random pauses on the client-side due to stream buffering.

Optimized the JobQueue startup initialization by reusing the results of the existing scheduled-jobs query to determine whether the queue is in use, allowing the system to skip the additional query for future scheduled jobs when current jobs are already present, thereby reducing database load and improving startup performance without changing observable behavior.

There was an oversight that resulted in endpoint level summary data being overwritten by group level summary data in situations such as the following:

sealed class MyGroup : Group
{
    public MyGroup()
    {
        Configure("group", ep => ep.Summary(s => s.Description = "group level text"));
    }
}

sealed class MyEndpoint : EndpointWithoutRequest
{
    public override void Configure()
    {
        Get("/something");
        Group<MyGroup>();
        Summary(s => s.Description = "endpoint level text"); //this would get loss due to the bug
    }
}

Given a request DTO class such as:

public class MyRequest 
{
    [RouteParam]
    public string? Something
}

When you don't supply a value for Something during testing with the routeless test helpers such as .GETAsync<>(), and empty query parameter would be appended to the request URL like so:

/my/endpoint?Something=

While this isn't inherently wrong, the common behavior in most REST clients, is to not send in a query parameter at all for when the value is empty. The test helpers will also follow suit from now on.

The default request binder was throwing an exception when a request DTO has an optional constructor argument that is a struct type like the following.

sealed class MyRequest(SomeStruct someOptionalStruct = default)
{
  ...
}