ServiceDefaults: discovery handler attached but no providers registered — factory HttpClient to any absolute URL fails

[omercelikdev]

Symptom

Any IHttpClientFactory client in a Goldpath app that calls an absolute URL (external IdP, webhook, third-party API) fails at request time:

System.InvalidOperationException: No provider which supports the provided service name, 'http://keycloak:8080', has been configured.
   at Microsoft.Extensions.ServiceDiscovery.ServiceEndpointWatcherFactory.CreateWatcher(String serviceName)

Found on the api-portal product (0.1.0-preview.6 train) wiring a dev token proxy to Keycloak in compose; any adopter with an outbound factory client hits the same wall.

Cause

GoldpathServiceDefaultsExtensions (line ~151) attaches the per-client discovery handler:

builder.Services.ConfigureHttpClientDefaults(http =>
{
    http.AddStandardResilienceHandler();
    http.AddServiceDiscovery();          // handler on every client…
});

…but never calls builder.Services.AddServiceDiscovery(), so no endpoint providers (configuration, DNS pass-through) exist. Every resolution attempt is refused. The Aspire reference template registers both.

Fix

Add provider registration next to the handler:

builder.Services.AddServiceDiscovery();

One line; pass-through then resolves plain DNS names (compose/K8s service names, external hosts) and the configuration provider honors services__name__http__0 announcements.

Workaround (until the train ships it)

Products call builder.Services.AddServiceDiscovery(); themselves right after AddGoldpathServiceDefaults() (api-portal does this with a delete-when-fixed comment).

DoD

• AddGoldpathServiceDefaults() registers discovery providers
• Regression test: a factory client resolves an absolute http://host:port URL under service defaults (pass-through)
• Ships on 0.1.0-preview.7; api-portal deletes its workaround on the train bump