Triage for dotnet/aspire#10452.
Repo filter: area-dashboard issues.
MihuBot version: 4431de.
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#10452: Regression when matching to database as uninstrumented peer by JamesNK
[Tool] Searching for database resource matching, uninstrumented peer, address matching database container, regression database match, pull/10411 (IncludeOpen=True, IncludeClosed=True, IncludeIssues=True, IncludePullRequests=True, Repository=dotnet/aspire)
[Tool] Obtained 2 comments for issue #10452: Regression when matching to database as uninstrumented peer
[Tool] Found 133 issues, 90 comments, 133 returned results (8906 ms)

Here are the most relevant related issues and discussions for issue #10452, "Regression when matching to database as uninstrumented peer":

1. PR #10411 (July 2025) - "Fix TryMatchAgainstResources to return false for multiple resource matches"

• Summary: This PR directly introduced the regression described in #10452. It changed the matching logic in ResourceOutgoingPeerResolver so that if multiple resources match an address, it now returns false (no match) instead of picking the first match. The intent was to avoid ambiguous peer resolution, but as a side effect, legitimate scenarios where multiple resources (e.g., a database and its container, or replicas) share the same address now result in no match at all.
• Key Details:
  • The new logic counts all matches and only returns true if exactly one resource matches.
  • If zero or multiple resources match, it returns false and sets out parameters to null.
  • The PR added comprehensive tests for ambiguous and single match scenarios.
• Relevant Comments:
  • JamesNK (the author of #10452) confirmed in the PR that he had implemented similar logic elsewhere and that the change here was the cause of the regression.
  • There was discussion about whether to match by name rather than by reference to avoid ambiguity with replicas.

2. Issue #10452 (July 2025) - "Regression when matching to database as uninstrumented peer"

• Summary: The issue itself describes that after #10411, outgoing calls to a database no longer match the database resource, likely because both the database and its container (or replicas) share the same address, causing the new logic to treat it as ambiguous and return no match.
• Key Comment: JamesNK adds that it also fails to match replicas when a request is made to a replica but the server span from the replica has not finished yet—previously, one of the replicas would be chosen.

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

• Summary: This PR extended the peer matching logic to support more resource types and added more robust address extraction and transformation logic. It is relevant because it increased the number of possible addresses that could match, making ambiguous matches more likely and thus more affected by the stricter logic in #10411.
• Key Comments: There was extensive discussion about how to extract and transform addresses, and about the need to cache possible endpoints to avoid recomputation. JamesNK noted that the logic for detecting resource changes needed to be extended to cover new properties used for matching.

4. PR #10370 (July 2025) - "Match name with ResourceCommandService"

• Summary: This PR, referenced by JamesNK in #10411, improved resource matching by allowing matches on resource name if there are no replicas, rather than requiring an exact reference match. This is relevant to the discussion about how to disambiguate between multiple resources with the same address.

5. PR #10412 (July 2025) - "[release/9.4] Fix TryMatchAgainstResources to return false for multiple resource matches"

• Summary: This is the backport of #10411 to the release branch, so the same regression would be present in the release/9.4 branch.

6. PR #1932 (January 2024) - "Transform outgoing address to try to find a resource match"

• Summary: This PR introduced logic to transform outgoing addresses to improve matching, such as handling different formats for SQL Server and Cosmos DB. It is part of the evolution of the matching logic that led to the current ambiguity problem.

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

• Summary: This issue led to the changes in PR #10340, which increased the number of addresses considered for matching and thus the likelihood of ambiguous matches.

8. PR #10382 (July 2025) - "[release/9.4] Support uninstrumented peer visualization for parameters, and resources with connection strings and github models"

• Summary: Backport of #10340, so the expanded matching logic is present in the release branch as well.

Summary of the Problem and Discussion

• The regression in #10452 is a direct result of the stricter ambiguity handling introduced in #10411. Now, if more than one resource matches an address (e.g., a database and its container, or multiple replicas), the resolver returns no match, breaking scenarios that previously worked.
• The expanded address extraction logic from #10340 and related work increased the likelihood of ambiguous matches.
• There is ongoing discussion about how to disambiguate between resources with the same address, with suggestions to match by name or to improve the way replicas are handled.
• The regression affects both matching to the main database resource and to replicas, as described in the issue comments.

Conclusion

• #10411 is the root cause of the regression.
• #10340 and related changes increased the likelihood of ambiguous matches.
• There is active discussion about how to resolve ambiguity, possibly by matching on resource name or improving replica handling.

If you are triaging this issue, it is a clear regression caused by a recent change, and the related discussions provide context and possible directions for a fix (e.g., relaxing the ambiguity rule, matching by name, or handling replicas differently).

References:

• PR #10411
• Issue #10452
• PR #10340
• PR #10370
• PR #10412
• PR #1932
• Issue #10338
• PR #10382