StackOverflowError when uploading sbom twice

[phimizs]

Current Behavior

I want to analyse a sbom genarted by cyclonedx-gomod on go source.
When uploading the sbom via UI or API the first time - everything is working as expected.
Uploading the same (or a new generated sbom) 2nd time on the same project leads to a StackOverflowError:

dtrack-apiserver-1  | 2024-05-16 06:46:05,630 INFO [BomUploadProcessingTask] Processing CycloneDX BOM uploaded to project: ee554573-55f6-45bd-9444-1bcae8beeced
dtrack-apiserver-1  | 2024-05-16 06:46:07,343 ERROR [LoggableUncaughtExceptionHandler] An unknown error occurred in an asynchronous event or notification thread
dtrack-apiserver-1  | java.lang.StackOverflowError: null
dtrack-apiserver-1  | 	at org.datanucleus.metadata.AbstractMemberMetaData.getAbsoluteFieldNumber(AbstractMemberMetaData.java:1920)
dtrack-apiserver-1  | 	at org.datanucleus.cache.L2CacheRetrieveFieldManager.processField(L2CacheRetrieveFieldManager.java:336)
dtrack-apiserver-1  | 	at org.datanucleus.cache.L2CacheRetrieveFieldManager.fetchObjectField(L2CacheRetrieveFieldManager.java:170)
dtrack-apiserver-1  | 	at org.datanucleus.state.StateManagerImpl.replacingObjectField(StateManagerImpl.java:2069)
dtrack-apiserver-1  | 	at alpine.model.ConfigProperty.dnReplaceField(ConfigProperty.java)
dtrack-apiserver-1  | 	at alpine.model.ConfigProperty.dnReplaceFields(ConfigProperty.java)
dtrack-apiserver-1  | 	at org.datanucleus.state.StateManagerImpl.replaceFields(StateManagerImpl.java:4369)
dtrack-apiserver-1  | 	at org.datanucleus.state.StateManagerImpl.replaceFields(StateManagerImpl.java:4393)
dtrack-apiserver-1  | 	at org.datanucleus.state.StateManagerImpl.initialiseForCachedPC(StateManagerImpl.java:724)
dtrack-apiserver-1  | 	at org.datanucleus.state.StateManagerFactoryImpl.newForCachedPC(StateManagerFactoryImpl.java:204)
dtrack-apiserver-1  | 	at org.datanucleus.ExecutionContextImpl.getObjectFromLevel2Cache(ExecutionContextImpl.java:5173)
dtrack-apiserver-1  | 	at org.datanucleus.ExecutionContextImpl.getObjectFromCache(ExecutionContextImpl.java:5064)
dtrack-apiserver-1  | 	at org.datanucleus.ExecutionContextImpl.findObject(ExecutionContextImpl.java:3112)
dtrack-apiserver-1  | 	at org.datanucleus.store.rdbms.query.PersistentClassROF.findObjectWithIdAndLoadFields(PersistentClassROF.java:550)
dtrack-apiserver-1  | 	at org.datanucleus.store.rdbms.query.PersistentClassROF.getObject(PersistentClassROF.java:454)
dtrack-apiserver-1  | 	at org.datanucleus.store.rdbms.query.ForwardQueryResult.nextResultSetElement(ForwardQueryResult.java:185)
dtrack-apiserver-1  | 	at org.datanucleus.store.rdbms.query.ForwardQueryResult$QueryResultIterator.next(ForwardQueryResult.java:436)
dtrack-apiserver-1  | 	at org.datanucleus.store.rdbms.query.ForwardQueryResult.processNumberOfResults(ForwardQueryResult.java:141)
dtrack-apiserver-1  | 	at org.datanucleus.store.rdbms.query.ForwardQueryResult.advanceToEndOfResultSet(ForwardQueryResult.java:169)
dtrack-apiserver-1  | 	at org.datanucleus.store.rdbms.query.ForwardQueryResult.closingConnection(ForwardQueryResult.java:318)
dtrack-apiserver-1  | 	at org.datanucleus.store.query.AbstractQueryResult.disconnect(AbstractQueryResult.java:106)
dtrack-apiserver-1  | 	at org.datanucleus.store.rdbms.query.AbstractRDBMSQueryResult.disconnect(AbstractRDBMSQueryResult.java:292)
dtrack-apiserver-1  | 	at org.datanucleus.store.rdbms.query.JDOQLQuery$1.managedConnectionPreClose(JDOQLQuery.java:746)
dtrack-apiserver-1  | 	at org.datanucleus.store.rdbms.ConnectionFactoryImpl$ManagedConnectionImpl.close(ConnectionFactoryImpl.java:532)
dtrack-apiserver-1  | 	at org.datanucleus.store.connection.AbstractManagedConnection.release(AbstractManagedConnection.java:92)
dtrack-apiserver-1  | 	at org.datanucleus.store.rdbms.ConnectionFactoryImpl$ManagedConnectionImpl.release(ConnectionFactoryImpl.java:371)
dtrack-apiserver-1  | 	at org.datanucleus.store.rdbms.query.JDOQLQuery.performExecute(JDOQLQuery.java:821)
dtrack-apiserver-1  | 	at org.datanucleus.store.query.Query.executeQuery(Query.java:2004)
dtrack-apiserver-1  | 	at org.datanucleus.store.query.Query.executeWithArray(Query.java:1893)
dtrack-apiserver-1  | 	at org.datanucleus.api.jdo.JDOQuery.executeInternal(JDOQuery.java:433)
dtrack-apiserver-1  | 	at org.datanucleus.api.jdo.JDOQuery.execute(JDOQuery.java:290)
dtrack-apiserver-1  | 	at alpine.persistence.AlpineQueryManager.getConfigProperty(AlpineQueryManager.java:1024)
dtrack-apiserver-1  | 	at org.dependencytrack.util.InternalComponentIdentifier.loadPatterns(InternalComponentIdentifier.java:84)
dtrack-apiserver-1  | 	at com.google.common.base.Suppliers$NonSerializableMemoizingSupplier.get(Suppliers.java:186)
dtrack-apiserver-1  | 	at org.dependencytrack.util.InternalComponentIdentifier.isInternal(InternalComponentIdentifier.java:60)
dtrack-apiserver-1  | 	at org.dependencytrack.util.InternalComponentIdentificationUtil.isInternalComponent(InternalComponentIdentificationUtil.java:33)
dtrack-apiserver-1  | 	at org.dependencytrack.tasks.BomUploadProcessingTask.processComponent(BomUploadProcessingTask.java:251)
dtrack-apiserver-1  | 	at org.dependencytrack.tasks.BomUploadProcessingTask.processComponent(BomUploadProcessingTask.java:262)
dtrack-apiserver-1  | 	at org.dependencytrack.tasks.BomUploadProcessingTask.processComponent(BomUploadProcessingTask.java:262)

I thought that will be fixed with #3357 (like mentioned here) - but problem still exists.
Similar issue #1905

Steps to Reproduce

1. Generate sbom for golang source
2. Upload sbom to a newly created project via UI
3. Download sbom via UI
4. Upload downloaded sbom again

Expected Behavior

Uploading a sbom more than one time should be processed correctly

Dependency-Track Version

4.11.0

Dependency-Track Distribution

Container Image

Database Server

H2

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

[nscuro]

@phimizs, please enable BOM Processing V2 in the administration panel under Configuration -> Experimental. That should resolve it.

Refer to the v4.11 changelog for Optimized BOM Ingestion. It will be the default for DT v4.12.

[phimizs]

Thanks @nscuro I missed the changelog entry.
With "BOM Processing V2" the issue is gone

[github-actions]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.