.NET: [Bug]: Microsoft.Agents.AI.Foundry.Hosting 1.17.0-preview.260804.1: container fails to start, "address already in use" on port 8088

[aherbert-shine]

Description

Description

Upgrading Microsoft.Agents.AI.Foundry.Hosting from 1.15.0-preview.260722.1 to 1.17.0-preview.260804.1 causes every hosted-agent container instance to crash on startup with a Kestrel port-binding conflict. This reproduces on every new session/conversation (not a stuck-compute-slot issue), making the agent completely unreachable (azd ai agent invoke returns HTTP 424 session_not_ready).

Repro

1. .NET 10 hosted agent using Microsoft.Agents.AI.Foundry.Hosting, minimal setup via AgentHost.CreateBuilder(args) + AddFoundryResponses + MapFoundryResponses().
2. Bump the package reference from 1.15.0-preview.260722.1 to 1.17.0-preview.260804.1.
3. azd deploy.
4. azd ai agent invoke <agent> "<msg>" --new-session --new-conversation (confirmed with a completely fresh session ID, ruling out session reuse/stuck compute).

Expected

Container starts and binds 0.0.0.0:8088 as before.

Actual

fail: Microsoft.Extensions.Hosting.Internal.Host[11]
      Hosting failed to start
      System.IO.IOException: Failed to bind to address http://0.0.0.0:8088: address already in use.
       ---> Microsoft.AspNetCore.Connections.AddressInUseException: Address already in use
       ---> System.Net.Sockets.SocketException (98): Address already in use
         at System.Net.Sockets.Socket.UpdateStatusAfterSocketErrorAndThrowException(...)
         ...
Unhandled exception. System.IO.IOException: Failed to bind to address http://0.0.0.0:8088: address already in use.
   at Azure.AI.AgentServer.Core.AgentHostApp.Run()
   at Program.<Main>$(String[] args) in /tmp/oryx-src/Program.cs:line 37
bash: line 1: <pid> Aborted   dotnet <agent>.dll

The invoking client then gets:

ERROR: POST .../responses?api-version=v1 failed with HTTP 424: 424 Failed Dependency
{
  "error": {
    "code": "session_not_ready",
    "message": "Session '<id>' did not become ready within the expected timeout. ..."
  }
}

Environment

• Microsoft.Agents.AI.Foundry.Hosting: 1.17.0-preview.260804.1 (regression); 1.15.0-preview.260722.1 works
• .NET 10, mcr.microsoft.com/dotnet/aspnet:10.0 base image, linux-x64, PublishReadyToRun=true
• Hosted via Foundry (azd ai agent / azure.yaml with infra.provider: microsoft.foundry)
• Dockerfile sets ENV ASPNETCORE_URLS=http://+:8088, EXPOSE 8088, ENTRYPOINT ["dotnet", "<agent>.dll"] unchanged between working/broken versions

Additional notes

Rolling back to 1.15.0-preview.260722.1 resolves the startup crash, but that version has a separate, unrelated bug: the Agent365Exporter (Microsoft.Agents.A365.Observability.Runtime.Tracing.Exporters.Agent365Exporter) throws System.ArgumentException: An item with the same key has already been added. Key: gen_ai.conversation.id in ExportFormatter.MapAttributes on every telemetry export batch, silently dropping all Application Insights telemetry (traces, requests, exceptions, dependencies, confirmed via direct KQL query showing zero ingested rows). Happy to open that as a separate issue if useful.

Code Sample

// Copyright (c) Microsoft. All rights reserved.

using Azure.AI.Projects;
using Azure.Identity;
using DotNetEnv;
using Microsoft.Agents.AI;
using Microsoft.Agents.AI.Foundry.Hosting;
using Microsoft.Extensions.AI;

Env.NoClobber().TraversePath().Load();

var projectEndpoint = new Uri(Environment.GetEnvironmentVariable("FOUNDRY_PROJECT_ENDPOINT")
    ?? throw new InvalidOperationException("FOUNDRY_PROJECT_ENDPOINT environment variable is not set."));
var deployment = Environment.GetEnvironmentVariable("AZURE_AI_MODEL_DEPLOYMENT_NAME") ?? "gpt-5.4-mini";
var credential = new ChainedTokenCredential(    new AzureCliCredential(), new ManagedIdentityCredential(new ManagedIdentityCredentialOptions()));

AIAgent agent = new AIProjectClient(projectEndpoint, credential)
    .AsAIAgent(
        model: deployment,
        instructions: "You are a friendly assistant. Keep your answers brief.",
        name: "observability",
        description: "An instrumented agent demonstrating Foundry hosted-agent observability.",
        tools:
        [
            AIFunctionFactory.Create(GetCurrentLocation, "GetCurrentLocation",
                "Get the current location of the user."),
            AIFunctionFactory.Create(GetWeather, "GetWeather",
                "Get the weather for a given location.")
        ]);

var builder = AgentHost.CreateBuilder(args);
builder.Services.AddFoundryResponses(agent);
builder.RegisterProtocol("responses", endpoints => endpoints.MapFoundryResponses());

var app = builder.Build();
app.Run();

static string GetCurrentLocation()
{
    string[] locations = ["New York", "London", "Paris", "Tokyo"];
    return locations[Random.Shared.Next(locations.Length)];
}

static string GetWeather(string location)
{
    string[] conditions = ["sunny", "cloudy", "rainy", "stormy"];
    var condition = conditions[Random.Shared.Next(conditions.Length)];
    var temperature = Random.Shared.Next(10, 31);
    return $"The weather in {location} is {condition} with a high of {temperature}°C.";
}

Error Messages / Stack Traces

fail: Microsoft.Extensions.Hosting.Internal.Host[11]
      Hosting failed to start
      System.IO.IOException: Failed to bind to address http://0.0.0.0:8088: address already in use.
       ---> Microsoft.AspNetCore.Connections.AddressInUseException: Address already in use
       ---> System.Net.Sockets.SocketException (98): Address already in use
         at System.Net.Sockets.Socket.UpdateStatusAfterSocketErrorAndThrowException(...)
         ...
Unhandled exception. System.IO.IOException: Failed to bind to address http://0.0.0.0:8088: address already in use.
   at Azure.AI.AgentServer.Core.AgentHostApp.Run()
   at Program.<Main>$(String[] args) in /tmp/oryx-src/Program.cs:line 37
bash: line 1: <pid> Aborted   dotnet <agent>.dll

Package Versions

Microsoft.Agents.AI.Foundry.Hosting 1.17.0-preview.260722.1

.NET Version

.NET 10

Additional Context

No response

[MilkyWay008]

The "address already in use" on a fresh container usually means something else in the image grabbed 8088 before Kestrel. Check if 1.17 wires an extra listener (health probe or a second host builder) or changed the entrypoint. ss -tlnp right after start shows who owns the port, and setting ASPNETCORE_URLS explicitly is a quick test. Diffing the 1.15 vs 1.17 image entrypoint usually exposes it fast.

[rliberoff]

I'm having exactly the same issue with version 1.19.0-preview.260822.1