### Summary The `Sbom::BuildDependencyGraphWorker` can experience performance and stability issues when processing large dependency graphs, particularly in the case of monorepos. This has affected several customers and can block adoption of [the dependency paths feature](https://docs.gitlab.com/user/application_security/dependency_list#dependency-paths). ### Current Behavior When the sidekiq job attempts to process very large dependency trees that are highly interconnected this can manifest as the following: * Jobs hang for hours without completing, blocking execution of others * Memory pressure on Sidekiq workers processing these jobs ### Root Cause The worker must construct the entire dependency tree in memory during processing. For projects with large dependency graphs (10K+ dependencies with high interconnectedness), this exceeds practical limits even with existing optimizations. This can be particularly problematic for projects uploading ~"Category:Container Scanning" SBOMs. ### Some possible solutions 1. Convert feature flag into per-project setting to allow switching between "Fast mode" (one path per dependency) and "Exhaustive mode" (all possible dependency paths) 1. https://gitlab.com/gitlab-org/gitlab/-/work_items/592063+ 1. Hard timeout on job ### Workaround #### Configure process specific sidekiq job routing The canonical recommendation is to configure [process specific routing rules](https://docs.gitlab.com/administration/sidekiq/processing_specific_job_classes/#routing-rules) to process jobs off the `sbom_graphs` queue on an isolated sidekiq worker. This ensures the expensive dependency graph processing does not block other background jobs. #### Disable beta feature flag For affected customers, disable the `dependency_paths` feature flag on projects with large dependency graphs: `Feature.disable(:dependency_paths, project)` **Note:** All dependencies and vulnerabilities continue to be ingested. Only the dependency path visualization changes from showing all possible paths to showing one possible path.