Fix OTLP endpoint resolution in isolated mode#16367
Merged
Conversation
When running under isolated mode (DcpPublisher__RandomizePorts=true), the dashboard listens on a randomized port that differs from the statically configured OTLP endpoint URL. Resources were still using the configured URL, causing traces and metrics to not reach the dashboard. Resolve the OTLP endpoint from the dashboard resource's EndpointReference in the DistributedApplicationModel when available. EndpointReference resolves lazily to the actual allocated URL, so it picks up the correct port regardless of randomization. Extract the dashboard endpoint lookup into a shared helper used by both RegisterOtlpEnvironment (all resources) and the container-specific OtlpEndpointReferenceGatherer. Fixes #16037
JamesNK
requested review from
danegsta,
davidfowl,
karolz-ms and
mitchdenny
as code owners
Contributor
|
🚀 Dogfood this PR with:
curl -fsSL https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.sh | bash -s -- 16367Or
iex "& { $(irm https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.ps1) } 16367" |
Contributor
There was a problem hiding this comment.
Pull request overview
Fixes OTLP exporter endpoint resolution when running in isolated mode (randomized proxy ports) by preferring the Aspire Dashboard’s allocated OTLP endpoint from the DistributedApplicationModel (via EndpointReference) and falling back to the existing config-based resolution when the dashboard isn’t present.
Changes:
- Resolve
OTEL_EXPORTER_OTLP_ENDPOINTfrom the dashboard resource’s OTLPEndpointReference(allocated URL) when available. - Extract shared dashboard OTLP endpoint lookup into
ResolveOtlpEndpointFromDashboardand reuse it from both env-var registration and DCP container gathering. - Add/update tests covering dashboard endpoint resolution, preference rules, and fallback behavior.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| tests/Aspire.Hosting.Tests/WithOtlpExporterTests.cs | Adds coverage for resolving OTLP endpoint from dashboard allocated endpoints (including preference + fallback cases). |
| src/Aspire.Hosting/OtlpConfigurationExtensions.cs | Uses dashboard EndpointReference to set OTLP endpoint/protocol when a dashboard is in the model; adds shared resolver helper. |
| src/Aspire.Hosting/Dcp/OtlpEndpointReferenceGatherer.cs | Reuses the shared dashboard OTLP endpoint resolver and fixes doc comment typos. |
…oard Catch InvalidOperationException when accessing ServiceProvider, which throws when the DI container hasn't been built yet (e.g. env var evaluation in tests without a fully built host). Falls back to config-based resolution.
JamesNK
added
the
area-app-model
Member
Author
|
@karolz-ms I think this change means the OTLP endpoint gather you added can be removed. There are no failing tests, and I tests an app and saw it use a different endpoint for containers with OTLP. Can you confirm this change is ok? |
davidfowl
reviewed
Apr 22, 2026
| { | ||
| model = context.ExecutionContext.ServiceProvider.GetService<DistributedApplicationModel>(); | ||
| } | ||
| catch (InvalidOperationException) |
Member
Author
There was a problem hiding this comment.
Take a look at ExecutionContext.ServiceProvider property. It throws if not in a completed state.
davidfowl
reviewed
Apr 22, 2026
| return null; | ||
| } | ||
|
|
||
| var dashboardResource = model.Resources.SingleOrDefault(r => StringComparers.ResourceName.Equals(r.Name, KnownResourceNames.AspireDashboard)) as IResourceWithEndpoints; |
Contributor
There was a problem hiding this comment.
As much as I don't want to claim performance is an issue, this will loop over all resources to find the dashboard for each resource that uses it.
Contributor
There was a problem hiding this comment.
This is true but I think it is also inevitable--we do not control at which point in the model lifecycle AddOtlpEnvironment() is called and thus whether the dashboard resource is present or not. So we have to search for it each time.
Contributor
There was a problem hiding this comment.
I know but I can still complain about it 😄
davidfowl
reviewed
Apr 22, 2026
| var (url, protocol) = OtlpEndpointResolver.ResolveOtlpEndpoint(configuration, otlpExporterAnnotation.RequiredProtocol); | ||
| context.EnvironmentVariables[KnownOtelConfigNames.ExporterOtlpEndpoint] = new HostUrl(url); | ||
| context.EnvironmentVariables[KnownOtelConfigNames.ExporterOtlpProtocol] = protocol; | ||
| var dashboardEndpoint = ResolveOtlpEndpointFromDashboard(context, otlpExporterAnnotation.RequiredProtocol); |
Contributor
There was a problem hiding this comment.
What about the otlp collector? Does this break that?
Member
Author
There was a problem hiding this comment.
I added a test. No it doesn't break it.
karolz-ms
approved these changes
Apr 22, 2026
Contributor
karolz-ms
left a comment
karolz-ms
left a comment
There was a problem hiding this comment.
Really like this change, thank you James
| return null; | ||
| } | ||
|
|
||
| var grpcEndpoint = dashboardResource.GetEndpoint(KnownEndpointNames.OtlpGrpcEndpointName); |
Contributor
There was a problem hiding this comment.
The reason why this works and makes me happy is that GetEndpoint() returns an EndpointReference that is not tied to any particular network. That reference is subsequently resolved in the context of the network that the resource using the dashboard is connected to.
…d use StringComparison
Contributor
|
🎬 CLI E2E Test Recordings — 74 recordings uploaded (commit View recordings
📹 Recordings uploaded automatically from CI run #24808814992 |
Contributor
|
No documentation PR is required for this change. Reason: This is a bug fix (OTLP endpoint resolution in isolated mode) with no user-facing documentation impact:
|
JamesNK
added a commit
that referenced
this pull request
Apr 23, 2026
This was referenced Apr 23, 2026
Closed
Closed
Closed
This was referenced Apr 25, 2026
Closed
Closed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
When running under isolated mode (
aspire start --isolated, which setsDcpPublisher__RandomizePorts=true), DCP assigns random ports to all proxied endpoints. The dashboard OTLP endpoint therefore listens on a different port than the statically configuredASPIRE_DASHBOARD_OTLP_ENDPOINT_URL. Resources were still using the configured URL viaHostUrl, causing traces and metrics to never reach the dashboard.This PR resolves the OTLP endpoint from the dashboard resource's
EndpointReferencein theDistributedApplicationModelwhen available.EndpointReferenceimplementsIValueProviderand resolves lazily to the actual allocated URL, so it picks up the correct port regardless of randomization. When no dashboard resource is present (e.g. tests, publish), it falls back to the existingHostUrl-based config behavior.The dashboard endpoint lookup is extracted into a shared helper (
ResolveOtlpEndpointFromDashboard) used by bothRegisterOtlpEnvironment(all resources) and the container-specificOtlpEndpointReferenceGatherer, eliminating duplicated logic.Fixes #16037
Checklist