After update to 4.10.*: Empty Audit Vulnerabilities lists and Uncaught internal server error: value = ... for column ""COMPONENT"."ID"" : The column index is out of range: 1, number of columns: 0.

SaberStrat commented 8 months ago

Current Behavior

After I updated 4.9.1 to 4.10.0 and then 4.10.1, the Audit Vulnerabilities list has been showing 0 entries for all projects and project versions. Can't say which of the two update step caused this.

Looking at the browser dev tools, the reason for the empty lists was that the /api/v1/findings API requests failed with HTTP status 500.

The 500s correlated with log entries like these, differing by the value = ... value:

2024-01-11 08:02:14,575 ERROR [GlobalExceptionHandler] Uncaught internal server error
javax.jdo.JDODataStoreException: Cannot set long parameter: value = 498978 for column ""COMPONENT"."ID"" : The column index is out of range: 1, number of columns: 0.
        at org.datanucleus.api.jdo.JDOAdapter.getJDOExceptionForNucleusException(JDOAdapter.java:605)
        at org.datanucleus.api.jdo.JDOQuery.executeInternal(JDOQuery.java:456)
        at org.datanucleus.api.jdo.JDOQuery.execute(JDOQuery.java:290)
        at org.dependencytrack.persistence.FindingsQueryManager.getAnalysis(FindingsQueryManager.java:169)
        at org.dependencytrack.persistence.FindingsQueryManager.getFindings(FindingsQueryManager.java:276)
        at org.dependencytrack.persistence.QueryManager.getFindings(QueryManager.java:1044)
        at org.dependencytrack.resources.v1.FindingResource.getFindingsByProject(FindingResource.java:92)
        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(Unknown Source)
        at java.base/java.lang.reflect.Method.invoke(Unknown Source)
        at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory.lambda$static$0(ResourceMethodInvocationHandlerFactory.java:52)
        at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:146)
        at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:189)
        at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:176)
        at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:93)
        at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:478)
       ...

I fixed this by manually restarting the apiserver container.

I don't know DT's inner workings, but this feels like the apiserver cached some intermediate DB state from when the DB was still processing update-related background data tasks, and kept working off of that, claiming silly things like the table having no columns.

Steps to Reproduce

have 4.9.1 apiserver and frontend running with projects in a docker-compose setup (also including an nginx and swagger-ui)
update the image tags for the apiserver and frontend to 4.10.0, save and do docker-compose up -d
have 4.10.0 running for a while (was over the x-mas das in my case)
update the image tags of the apiserver to 4.10.1, save and do `docker-compose up -d

Expected Behavior

Audit Vulnerabilities should not be empty and I shouldn't have to manually restart the apiserver if the Change Log didn't recommend it.

Dependency-Track Version

4.10.1

Dependency-Track Distribution

Container Image

Database Server

PostgreSQL

Database Server Version

13.2.0

Browser

Google Chrome

Checklist

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

nscuro commented 8 months ago

Thanks for reporting @SaberStrat!

I've seen something similar occasionally and can only speculate that this is caused by race conditions in the ORM. There are two query compilation steps involved, and both of them have caches. The fact that the issue resolved after a restart strongly suggests that it is indeed a caching issue.

I've not yet been able to reliably reproduce it, so I couldn't raise an issue or propose a fix to the ORM's codebase so far.

SaberStrat commented 8 months ago

You mean https://github.com/DependencyTrack/dependency-track/issues/2061 being similar @nscuro?

nscuro commented 8 months ago

Yup, I suspect these two issues have the same root cause.

nscuro commented 3 months ago

Confirmed to be the same as #2061. Closing as duplicate.

github-actions[bot] commented 2 months ago

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.

DependencyTrack / dependency-track