dependency-track icon indicating copy to clipboard operation
dependency-track copied to clipboard

Dependency Graph for Individual Dependency Can Lead to Infinite Recursion

Open msymons opened this issue 5 months ago • 3 comments

Current Behavior

An SBOM that contains 370 components and has 12400 lines (700 kb) is succesfully being imported to Dependency-Track v4.12.3 but then has problems with displaying the graph:

  • Opening the graph via the dependency graph tab and then expanding it bit by bit seems to have no problems.
  • Opening many "filtered graphs" (eg click on graph icon on components tab gives no problems for many components.
  • SOME components give a perpetual "loading" message and DT is now unresponsive in that browser tab... it it necessary to close the tab.

The problem SBOM has been provided "out of channel" and the defect has been reproduced. There seems to be an infinite recursion.

Steps to Reproduce

  1. Create a new project
  2. Upload SBOM
  3. Navigate to Components tab and click on the tree icon for an individual component.
  4. Clicking on link for some components results in "loading message" that does not go away... the graph never loads.
  5. As an aide-memoire, the SBOM that was supplied has problems with viewing the graphs for logback-classic and snakeyaml (amongst others).

The SBOM was generated using cyclonedx-gradle-plugin v2.0.0

Expected Behavior

The filtered graphs (graphs for specific components) should succesfully load

Dependency-Track Version

4.13.2

Dependency-Track Distribution

Container Image

Database Server

PostgreSQL

Database Server Version

14.17

Browser

Google Chrome

Checklist

msymons avatar Jul 09 '25 13:07 msymons

In the recent community meeting (August 2025) this was announced to be fixed with the upcoming release. That is great news 👍, it's been bothering us for some time.

This maybe the same bug as described in #4362.

fupgang avatar Aug 18 '25 11:08 fupgang

Have to move this to 4.13.5 because we have to get #4742 out ASAP. I tried fixing as many of the other (trivial) issues we had planned for 4.13.4 as possible, but unfortunately this one is not trivial.

nscuro avatar Aug 26 '25 09:08 nscuro

Since this bug still bothers us, I took a deeper look at the implementation of ProjectDependencyGraph.

Problem

The dependency graph is rendered with vue2-org-tree, which generates a strictly hierarchical representation. Though the layout is nice and clean for small projects, it gets confusing for medium projects and finally unusable for larger projects. The problem is growing redundancy.

For each component, all components it depends on are added to the tree. Their dependencies are added, too. This happens regardless if a component is already rendered. Therefore complete subtrees maybe shown multiple times.

Here is an example with 3 components:

Image

This simply adds up. For larger projects (e.g. > 500 components) there maybe more than 10000 nodes resulting in out of memory errors. See for example the SBOM attached to #4362: it has 452 components, the rendering fails when searching for some components. I limited the number of nodes created, that is rendered only a partial tree. The graph renders fine, the app is responsive. The result is barely useful:

Image

I zoomed out, the graph is huge and highly redundant.

Recursion

There seems to be an infinite recursion.

Recursion does not seem to be a problem to me. I created a project with a cyclic dependency (A <--> B). The dependency graph renders fine.

Image

This is probably implemented by keeping track of the path to a node (see gatheredKeys) and stop creating an additional child node if the corresponding component is already on that path.

Possible Solutions

Network

Replace vue2-org-tree with another component that renders a network of nodes. Each component is represented as a single node only.

Trimming

Reduce the number of nodes. For example, render only the shortest path to a component. Using the project from the example above that could be:

Image

@nscuro, if nobody is currently working on this issue, I could work out a fix and provide a pull request. I would first try to render less nodes.

fupgang avatar Nov 28 '25 14:11 fupgang