Repository: DependencyTrack/dependency-track

Issue #2131: Error while uploading same SBOM Second time
Created: 2022-11-07T06:53:08Z
The defect may already be reported! Please search for the defect before creating one.
Current Behavior:
When I upload the SBOM in Dependency Track for the First time in a new project it uploads successfully without any error logs and also reports the correct number of Components, but I upload the same SBOM in the same project again it shows error logs and reports the incorrect count of components
Logs When I upload SBOM First time

Number of Components: 1686
Logs When I upload the SBOM Second time

Number of Components: 1611
Steps to Reproduce:
Step 1: Create a New project
Step 2: Upload SBOM in the New project
Step 3: Monitor the logs and Number of components shown in the Dependency track
Step 4: Again upload the same SBOM in the Same project
Step 5: Monitor the logs and Number of components shows in the Dependency track
Expected Behavior:
Environment:
Report the Same number of components without any error logs when we upload SBOM second time in same project

Dependency-Track Version: 4.6.2
Distribution: Docker
BOM Format & Version: JSON, Cyclonedx 1.4
Database Server: H2 and PostgreSQL
Browser: Chrome

Duplicate issue #2265: Incompatibility with SBOM from @cyclonedx/cyclonedx-npm
Created: 2022-12-09T16:50:55Z
Current Behavior
We found some kind of incompatibility with some SBOMs generated by @cyclonedx/cyclonedx-npm. We could not reproduce this with SBOMs from the older NPM tool or other sbom tools.
When a project exists with a BOM from @cyclonedx/cyclonedx-npm, and you try to upload a very different BOM file or one generated by another tool, upload API will return 200, but the "Last BOM Upload" timestamp will not update, neither will the components reflect what the latest uploaded BOM contained.
The log shows an error:
2022-12-07 12:12:15,441 [] INFO [org.dependencytrack.tasks.BomUploadProcessingTask] Processing CycloneDX BOM uploaded to project: 6c3b8a36-7454-4a8a-934d-5e28a0c6258c
2022-12-07 12:12:17,067 [] INFO [org.dependencytrack.tasks.BomUploadProcessingTask] Identified 0 new components
2022-12-07 12:12:17,067 [] INFO [org.dependencytrack.tasks.BomUploadProcessingTask] Processing CycloneDX dependency graph for project: 6c3b8a36-7454-4a8a-934d-5e28a0c6258c
2022-12-07 12:12:21,220 [] ERROR [org.dependencytrack.tasks.BomUploadProcessingTask] Error while processing bom
javax.jdo.JDOObjectNotFoundException: Object with id "org.dependencytrack.model.Component:0" not found !
	at org.datanucleus.api.jdo.JDOAdapter.getJDOExceptionForNucleusException(JDOAdapter.java:634)
	at org.datanucleus.api.jdo.JDOPersistenceManager.getObjectById(JDOPersistenceManager.java:1726)
	at org.dependencytrack.persistence.ComponentQueryManager.recursivelyDelete(ComponentQueryManager.java:414)
	at org.dependencytrack.persistence.ComponentQueryManager.reconcileComponents(ComponentQueryManager.java:517)
	at org.dependencytrack.persistence.QueryManager.reconcileComponents(QueryManager.java:771)
	at org.dependencytrack.tasks.BomUploadProcessingTask.inform(BomUploadProcessingTask.java:138)
	at alpine.event.framework.BaseEventService.lambda$publish$0(BaseEventService.java:101)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
	at java.base/java.lang.Thread.run(Unknown Source)
Caused by: org.datanucleus.exceptions.NucleusObjectNotFoundException: Object with id "org.dependencytrack.model.Component:0" not found !
	at org.datanucleus.store.rdbms.request.FetchRequest.execute(FetchRequest.java:473)
	at org.datanucleus.store.rdbms.RDBMSPersistenceHandler.fetchObject(RDBMSPersistenceHandler.java:354)
	at org.datanucleus.state.StateManagerImpl.loadFieldsFromDatastore(StateManagerImpl.java:1608)
	at org.datanucleus.state.StateManagerImpl.validate(StateManagerImpl.java:5570)
	at org.datanucleus.ExecutionContextImpl.findObject(ExecutionContextImpl.java:3446)
	at org.datanucleus.ExecutionContextImpl.findObject(ExecutionContextImpl.java:2928)
	at org.datanucleus.api.jdo.JDOPersistenceManager.getObjectById(JDOPersistenceManager.java:1721)
	... 8 common frames omitted

Steps to Reproduce

Upload a BOM file generated by @cyclonedx/cyclonedx-npm (not sure if special conditions apply here regarding the packages, we identified at least 2 projects BOMs showing this behaviour)
Upload a very different BOM file to update the Dependency-Track content. In our case we replaced the NPM tool in one project with the webpack-cyclonedx tool, which produced a completely different BOM (as expected). But it also reproduces when just import a BOM from any other tool or project
When trying to upload another bom again and again to the same project you will notice more and more of the old components are being deleted, doing it often enough will result eventually in a success at some point when all old components are deleted.

Expected Behavior

BOM processing should not fail, result after processing should reflect the new BOM, no matter what was in the old BOM
If anything fails, I would expect nothing to be changed instead changing it step-by-step during multiple attempts. Can we use transactions here?

Dependency-Track Version
4.6.2
Dependency-Track Distribution
Container Image
Database Server
Microsoft SQL Server
Database Server Version
No response
Browser
Google Chrome
Checklist

 I have read and understand the contributing guidelines
 I have checked the existing issues for whether this defect was already reported

Closing comment (2023-07-06T11:19:36Z): @rkg-mm Okay from your side to close this issue as duplicate of #2131? Am trying to consolidate issues related on this topic.