YARP container fails to resolve named endpoint via service discovery after upgrade to Aspire.Hosting.Yarp 13.2.1

[paulomorgado]

YARP container fails to resolve named endpoint via service discovery after upgrade to Aspire.Hosting.Yarp 13.2.1

Description

After upgrading from Aspire.Hosting.Yarp 13.1.2 to 13.2.1 (and Aspire.AppHost.Sdk 13.1.2 → 13.2.1), a YARP gateway container fails to resolve named endpoints configured via WithConfiguration / AddRoute. The YARP reverse proxy falls through to DNS hostname resolution instead of using the Aspire service discovery mechanism.

This worked correctly with version 13.1.2.

Reproduction

AppHost setup:

var builder = DistributedApplication.CreateBuilder(args);

var api = builder.AddProject<Projects.MyApi>("myapi",
    options =>
    {
        options.LaunchProfileName = null;
        options.ExcludeLaunchProfile = true;
        options.ExcludeKestrelEndpoints = true;
    })
    .WithHttpEndpoint(env: "PORT")
    .WithEndpoint(name: "prometheus", scheme: "http", env: "PROMETHEUS_PORT");

var gateway = builder.AddYarp("gateway");

builder.Eventing.Subscribe<BeforeStartEvent>((evt, ct) =>
{
    var prometheusEndpoint = api.GetEndpoint("prometheus");
    gateway.WithConfiguration(yarp =>
    {
        yarp
            .AddRoute("/prometheus/myapi/metrics", prometheusEndpoint)
            .WithTransformPathRemovePrefix("/prometheus/myapi");
    });

    return Task.CompletedTask;
});

builder.Build().Run();

Expected behavior

The YARP gateway container should resolve http://_prometheus.myapi via Aspire's service discovery, using the services__myapi__prometheus__0 environment variable injected into the container.

Actual behavior

The YARP container receives these environment variables:

# Service discovery - only 'http' endpoint, no 'prometheus' endpoint
services__myapi__http__0 = http://aspire.dev.internal:33945

# Named endpoint reference (non-service-discovery format)
MYAPI_PROMETHEUS = http://aspire.dev.internal:33945

# YARP destination using service discovery format
REVERSEPROXY__CLUSTERS__cluster_myapi__DESTINATIONS__destination1__ADDRESS = http://_prometheus.myapi

Note that services__myapi__prometheus__0 is missing. The MYAPI_PROMETHEUS env var contains the correct URL but is not in the services__ format that Aspire's service discovery resolver uses.

As a result, when Prometheus scrapes /prometheus/myapi/metrics through the gateway, YARP logs:

info: Yarp.ReverseProxy.Forwarder.HttpForwarder[9]
      Proxying to http://myapi/metrics HTTP/2 RequestVersionOrLower

warn: Yarp.ReverseProxy.Forwarder.HttpForwarder[48]
      Request: An error was encountered before receiving a response.
      System.Net.Http.HttpRequestException: Name or service not known (myapi:80)
       ---> System.Net.Sockets.SocketException: Name or service not known

The service discovery strips the _prometheus. prefix but cannot resolve myapi via the services__ env vars (only http is present, not prometheus), so it falls through to DNS resolution which fails because myapi is a project resource running on the host, not a container in the Docker network.

Versions

• Aspire.AppHost.Sdk: 13.2.1 (worked with 13.1.2)
• Aspire.Hosting.Yarp: 13.2.1 (worked with 13.1.2)
• OS: Windows 11
• .NET: 10.0
• Container runtime: Docker Desktop

Additional context

• The project resources (myapi) are .NET project resources, not containers.
• The prometheus endpoint is a dynamically allocated port added via .WithEndpoint(name: "prometheus", scheme: "http", env: "PROMETHEUS_PORT").
• The gateway is a container resource (mcr.microsoft.com/dotnet/nightly/yarp:2.3-preview).
• The AddRoute API receives the endpoint reference (api.GetEndpoint("prometheus")), which should cause Aspire to inject the corresponding services__myapi__prometheus__0 environment variable into the YARP container, but only services__myapi__http__0 is injected.

[paulomorgado]

For this to work, I had to add the old style environment variables (services__myservice__myendpoint__0 = https://localhost:5001).

[alx-sinc]

This seems to be a breaking change in Aspire version 13.2. as documented here: https://aspire.dev/whats-new/aspire-13-2/#%EF%B8%8F-breaking-changes

The weird thing, though, is that service discovery with named endpoints is still described in the manual: https://aspire.dev/fundamentals/service-discovery/#named-endpoints

I have the same issue. In my service I have two named endpoints, and now I cannot use them in service discovery anymore, as I cannot tell which one is which. Sure, I could look up the other environment variables, but that is not the meaning behind service discovery, I would say.

[paulomorgado]

This was a terrible idea.

If you don't name your endpoints, they are named after the HTTP schema.

If you name your endpoints differently, it's because you have more than one.

The only fix for this, is adding the ability to declare the endpoint name when adding references.