Triage for dotnet/aspire#10695.
Repo filter: area-dashboard issues.
MihuBot version: 2b6db8.
Ping MihaZupan for any issues.

This is a test triage report generated by AI, aimed at helping the triage team quickly identify past issues/PRs that may be related.
Take any conclusions with a large grain of salt.

dotnet/aspire#10695: Add link to outgoing uninstrumented peer resource by JamesNK
[Tool] Searching for uninstrumented peer resource, span detail link resource, span detail outgoing resource, link to peer resource, span resource mention peer (IncludeOpen=True, IncludeClosed=True, IncludeIssues=True, IncludePullRequests=True, Repository=dotnet/aspire)
[Tool] Found 76 issues, 169 comments, 76 returned results (16337 ms)

Here are the most relevant related issues and discussions for issue #10695, "Add link to outgoing uninstrumented peer resource":

1. PR #10340 (July 2025) - Support uninstrumented peer visualization for parameters, and resources with connection strings and github models

• Summary: This PR significantly extends the uninstrumented peer visualization mechanism in Aspire, allowing outgoing calls from parameters, connection strings, and GitHub models resources to be visualized as referenced peers in the trace timeline. It includes robust logic for extracting peer addresses from various resource properties and ensures consistent address matching. There is extensive discussion about how to parse and match addresses, cache resource addresses, and recompute them when resources change.
• Relevant to #10695: The PR and its discussion focus on improving the trace UI to better represent outgoing calls to uninstrumented peers, which is directly related to the request in #10695 to show and link the uninstrumented peer resource in span details. There is also mention of caching and displaying resource names for outgoing peers.
• Notable comments:
  • davidfowl and JamesNK discuss the need to cache and recompute resource addresses for efficient peer resolution.
  • The PR was merged and backported to release/9.4 (PR #10382).

2. Issue #10338 (July 2025) - Support uninstrumented peer visualization for parameters, connection strings, and GitHub models resources

• Summary: This issue is the original feature request that led to PR #10340. It describes the need to extend uninstrumented peer visualization to parameters, connection strings, and GitHub models, so that outgoing calls from these resource types are displayed in the Traces dashboard.
• Relevant to #10695: The work here is foundational to the improvements being requested in #10695, as it enables the dashboard to visualize more types of outgoing uninstrumented peers.

3. PR #1040 (Nov 2023) - Tracing UI displays resource name for outgoing resources

• Summary: This PR introduced the feature where the tracing UI uses the outgoing peer address to look up and display the resource name, rather than just the address, for outgoing peers. It describes the logic for mapping addresses to resource names and discusses the coupling between telemetry and hosting.
• Relevant to #10695: This is the initial implementation of showing resource names for outgoing peers, which #10695 seeks to further improve by adding explicit links in the span detail view.
• Notable comments:
  • davidfowl raises concerns about how this will work in deployed environments, not just development.

4. PR #8883 (Apr 2025) - Treat uninstrumented outgoing peers as instrumented resources in dashboard UI

• Summary: This PR made uninstrumented outgoing peers appear as peer apps in the trace UI, both in the filter dropdown and in the span summary. It also improved the performance of resource change events and made the dashboard resource client a singleton.
• Relevant to #10695: This work is a precursor to the current request, as it made uninstrumented peers more visible and integrated in the trace UI.

5. PR #9030 (Apr 2025) - Only display trace menu option for uninstrumented peer resources

• Summary: This PR ensures that the trace option is only displayed for uninstrumented peer resources, refining the UI logic for when trace links are shown.
• Relevant to #10695: It is part of the ongoing refinement of how uninstrumented peers are represented and linked in the dashboard.

6. PR #10456 (July 2025) - Revert peer matching logic to fix database resource resolution regression

• Summary: This PR reverted a change that caused database calls to uninstrumented peers to no longer match their corresponding resources. The fix restored the "first one wins" logic for peer matching.
• Relevant to #10695: Accurate peer matching is essential for linking outgoing peers to the correct resource in the UI, which is a prerequisite for the feature requested in #10695.

7. PR #5946 (Sep 2024) - Span details fixes

• Summary: This PR fixed errors in the span details view and improved the display of span and details headers, including for links and backlinks sections.
• Relevant to #10695: It shows ongoing improvements to the span details UI, which is the context for the requested feature.

8. Issue #2577 (Mar 2024) - Aspire Dashboard: Traces: Span links aren't shown in span details

• Summary: This issue requests that span links be shown in the span details view, including links to other spans (not just peers). There is discussion about how other UIs represent span links and what users expect when clicking them.
• Relevant to #10695: The discussion here is directly related to the idea of linking from span details to related resources or spans.

9. PR #1865 (Jan 2024) - Trace detail page - customize peer icons based on span attributes

• Summary: This PR improved the trace detail page by customizing peer icons based on span attributes, such as showing a database icon for database calls.
• Relevant to #10695: It is part of the ongoing effort to make span details more informative and visually clear, which aligns with the goal of linking to peer resources.

Conclusions

• There is a clear progression of work in Aspire to improve the visibility and linking of outgoing uninstrumented peer resources in the trace UI.
• The most recent and relevant work is in PR #10340 and its related issue #10338, which lay the groundwork for the feature requested in #10695.
• Earlier work (PR #1040, PR #8883, PR #9030) established the basic mechanisms for mapping outgoing peer addresses to resource names and displaying them in the UI.
• There is ongoing discussion about how to best represent and link these peers in the span details view, including UI/UX considerations and technical challenges around peer matching and resource caching.

If you are triaging #10695, you should reference these related issues and PRs, especially #10340 and #10338, as they are directly relevant to the requested feature.