Reconcile bare/rich component Ids in DependencyGraphs

[AMaini503]

Summary

Follows up on PR #1760 which reconciled bare/rich component identities in \ComponentsFound. This PR applies the same reconciliation to \DependencyGraphs.

Problem

After #1760, when a detector produces rich Ids (with DownloadUrl/SourceUrl) and another detector produces bare Ids for the same package at the same location, \ComponentsFound\ correctly drops the bare entries. However, \DependencyGraphs\ still contains both bare and rich nodes as separate graph keys — referencing Ids that no longer exist in \ComponentsFound.

Solution

Adds a post-processing step in \DefaultGraphTranslationService\ (after \AccumulateAndConvertToContract) that reconciles bare graph nodes into their rich counterparts:

• Merges outbound edges: bare node's edges are unioned into all rich counterparts
• Rewrites inbound edges: other nodes' edges pointing to bare Ids are rewritten to rich Ids
• Migrates metadata sets: ExplicitlyReferenced, DevDependencies, Dependencies
• Filters self-edges introduced by rewriting
• Handles multiple rich variants (e.g., same package from different registries)
• Leaves bare-only nodes unchanged (no rich counterpart = no reconciliation needed)

Testing

• 10 unit tests covering: Paul's duplication scenario, multi-rich variants, bare-only (no-op), rich-only (no-op), inbound edge rewriting, self-edge prevention, leaf preservation, null/empty collections, multiple locations
• All 151 Orchestrator tests pass
• Benchmark scan on GregTestRepo: identical \ComponentsFound\ and \DependencyGraphs\ vs main (safe no-op when no detectors produce rich Ids yet)

Related

• WI: AB#2372676
• Spec: Component-Identity-Merging
• Prior PR: Reconcile bare/rich component identities in ComponentsFound #1760

[Copilot]

Pull request overview

This PR extends the bare-vs-rich component identity reconciliation (previously applied to ComponentsFound) to also reconcile node IDs inside DependencyGraphs, ensuring graph keys and metadata sets reference IDs that still exist after component merging.

Changes:

• Adds a post-processing reconciliation step in DefaultGraphTranslationService to merge bare graph nodes into rich counterparts (per-location), rewriting edges and metadata sets.
• Introduces unit tests validating bare→rich merging behavior across multiple scenarios (multi-rich variants, inbound rewrite, self-edge prevention, no-op cases, multi-location).

Show a summary per file

File	Description
src/Microsoft.ComponentDetection.Orchestrator/Services/GraphTranslation/DefaultGraphTranslationService.cs	Builds dependency graphs once, then reconciles bare IDs to rich IDs by rewriting nodes/edges and metadata sets.
test/Microsoft.ComponentDetection.Orchestrator.Tests/Services/ReconcileDependencyGraphIdsTests.cs	Adds targeted unit tests covering reconciliation behavior and edge cases.

Copilot's findings

Comments suppressed due to low confidence (1)

src/Microsoft.ComponentDetection.Orchestrator/Services/GraphTranslation/DefaultGraphTranslationService.cs:212

• Merging bare outbound edges into rich nodes can create an empty edge-set after rewrite/self-edge filtering, but the graph currently keeps an empty HashSet. This differs from the existing convention where leaf nodes serialize with a null value (not an empty array). After merging, consider setting the value back to null when the resulting edge set is empty.

                if (bareEdges != null)
                {
                    newGraph[richId] ??= [];
                    foreach (var edge in bareEdges)
                    {
                        foreach (var rewritten in RewriteId(edge))
                        {
                            if (rewritten != richId)
                            {
                                newGraph[richId].Add(rewritten);
                            }
                        }
                    }
                }

• Files reviewed: 2/2 changed files
• Comments generated: 2

[github-actions]

👋 Hi! It looks like you modified some files in the Detectors folder.
You may need to bump the detector versions if any of the following scenarios apply:

• The detector detects more or fewer components than before
• The detector generates different parent/child graph relationships than before
• The detector generates different devDependencies values than before

If none of the above scenarios apply, feel free to ignore this comment 🙂

[Copilot]

Copilot's findings

• Files reviewed: 2/2 changed files
• Comments generated: 1

[AMaini503]

The CheckDetectorsRunTimesAndCounts verification test failure is a flaky timing assertion — it passed on a previous run of the same commit (run 24577433955).

Local scan times on a clean build:

• Main: 28.87s
• This branch: 39.53s

Both well within the 75% drift threshold (28.87 + 21.65 = 50.52s). CI runners just had higher variance.

[Copilot]

Copilot's findings

• Files reviewed: 2/2 changed files
• Comments generated: 1

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 0.0%. Comparing base (4eb4071) to head (62bca0d).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@     Coverage Diff      @@
##   main   #1784   +/-   ##
============================
============================

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.