Context-Based Endpoint Resolution does not seem to work correctly when using "WithEnvironment"

[b-enigma-con]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

According to article Configuring, Referencing, and Resolving Endpoints in .NET, endpoints should be resolved based on their context. When spinning up 2 containers and using "WithEnvironment", as decribed in mentioned document, the host name is always resolved as "localhost", instead of the target container hostname.This issue was encountered when following up on advice given in this issue: issue #8561

Expected Behavior

I would expect the referenced containers hostname to be resolved instead of the value "localhost".

Steps To Reproduce

The code below is all that's needed to reproduce the issue. It makes no sense for RabbitMQ to refer to Redis, but in the end these are "just" two containers refering to each other.

var builder = DistributedApplication.CreateBuilder(args);

var redis = builder.AddRedis("redis");

builder.AddRabbitMQ("rabbitmq")
    .WithEnvironment(context =>
    {
        var endpoint = redis.GetEndpoint("tcp");

        // Use .Property to access Host and Port expressions and defer evaluation
        var redisHost = endpoint.Property(EndpointProperty.Host);
        var redisPort = endpoint.Property(EndpointProperty.Port);

        // Set these values as REDIS_HOST/PORT on the target resource
        context.EnvironmentVariables["REDIS_HOST"] = redisHost;
        context.EnvironmentVariables["REDIS_PORT"] = redisPort;
    });


builder.Build().Run();

Exceptions (if any)

No response

.NET Version info

9.0.201

Anything else?

No response

[davidfowl]

Could be a regression.

cc @adamint

[afscrome]

Looks like EndpointProperty.Url is correctly resolving, but EndpointProperty.Host / EndpointProperty.Ipv4Host are not.

var redis = builder.AddRedis("redis");
var endpoint = redis.GetEndpoint("tcp");

builder.AddRabbitMQ("rabbitmq")
    .WithEnvironment("REDIS_HOST", $"{endpoint.Property(EndpointProperty.Host)}")
    .WithEnvironment("REDIS_IPV4HOST", $"{endpoint.Property(EndpointProperty.IPV4Host)}")
    .WithEnvironment("REDIS_URL", $"{endpoint.Property(EndpointProperty.Url)}")
    ;

Reproed on both 9.1.0, and 9.2.0-preview.1.25204.9

  <Sdk Name="Aspire.AppHost.Sdk" Version="9.1.0" />
  <ItemGroup>
    <PackageReference Include="Aspire.Hosting.AppHost" Version="9.1.0" />
    <PackageReference Include="Aspire.Hosting.Azure.Storage" Version="9.1.0" />
    <PackageReference Include="Aspire.Hosting.Redis" Version="9.1.0" />
    <PackageReference Include="Aspire.Hosting.RabbitMq" Version="9.1.0" />
  </ItemGroup>

[davidfowl]

Excellent that it's not a regression, just a bug.

[davidfowl]

Logic will be here:

aspire/src/Aspire.Hosting/ApplicationModel/ExpressionResolver.cs

Line 8 in 5becd83

internal class ExpressionResolver(string containerHostName, CancellationToken cancellationToken, bool sourceIsContainer)

[davidfowl]

Oh I think I recall why we did this. We don't blindly replace the host and port individually. We need to see both the host and the port to replace them.

[afscrome]

Do you recall why that is? With EndpointProperty.Port and EndpointProperty.TargetPort, I can sort of see why we didn't remap them, but with Host, we don't expose a way to get the resolve host.

This is also getting even more confusing in 9.2 with the addition of EndpointProperty.HostAndPort as it's very counter intuitive that EndpointProperty.HostAndPort gives you something completely different to concatenating Host and Port separately.

builder.AddRabbitMQ("rabbitmq")
    .WithEnvironment("REDIS_HOST", $"{endpoint.Property(EndpointProperty.Host)}")
    .WithEnvironment("REDIS_PORT", $"{endpoint.Property(EndpointProperty.Port)}")
    .WithEnvironment("REDIS_HOSTANDPORT", $"{endpoint.Property(EndpointProperty.HostAndPort)}")
    ;

[afscrome]

I guess it's related not fully supporting #7153 . When resolving an endpoint to yourself, you usually (but not always) want the Port to reference your internal port, not your external one. That however is likely not the case if referencing the host/port of an endpoint for another resource (which is happening in this case).

[davidfowl]

We don’t want to blindly replace the port as you might actually want the host port and not the target port. Generally this is an areas of ambiguity and we may just need to design the concept of “which network” you are resolving for with a way to override.