Spring JPA exceptions are captured and not visible in the application logs

[michalwilk96]

Hello,
Recently I observed the following issue in my Java application with Spring Boot framework.
Opentelemetry agent is attached as a jar to the configuration.
If any spring data jpa repository interface is executed and it throws an exception (Runtime), then it's automatically captured and visible on Kibana APM error (with the source of opentelemetry java agent). What's interesting - the log error is not visible in the application logs, even if the method that throws the error is in the try-catch block.
Example exception: jakarta.persistence.NoResultException.

Have you ever observed such an "issue"?

[hanswesterbeek]

Hi @michalwilk96,

We have observed the same issue. What happens is that Spring-data uses the hibernate-api in such a way that the span for that invocation is flagged as an Error when it shouldn't be. This false-positive results in huge amounts of stack-trace data being logged. We're trying to find an elegant solution.

[trask]

sorry, I'm still not following clearly enough to help, could you post a small repro (preferably as a github repository), along with instructions how to run and see the behavior you're seeing?

[pzgadzaj-equinix]

I also run into this issue, when hibernate JPA internally throws:
jakarta.persistence.NoResultException: No result found for query []
at org.hibernate.query.spi.AbstractSelectionQuery.getSingleResult(AbstractSelectionQuery.java:567)

Exception is then catched internally by JPA but anyway it marks the Span as ERROR leading to enormous number of ERROR span during normal operations for the application

[trask]

@pzgadzaj-equinix @garymabin please provide a minimal application that reproduces the issue along with any necessary instructions if you wish someone to take a look at this, thanks!

[binchen-lin]

Hello We are facing exactly the same issue.
A pseudo example could be using Spring Data:

Optional<SomeObject> findById(UUID id);

In case of no match, an empty Optional will be returned. => Which is actually OK. However, we noticed in monitoring quite few those Exceptions logged as ERROR(we are using the OTEL JAVA Agent):

at org.hibernate.query.spi.AbstractSelectionQuery.getSingleResult(AbstractSelectionQuery.java:558) at jdk.internal.reflect.DirectMethodHandleAccessor.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.springframework.orm.jpa.SharedEntityManagerCreator$DeferredQueryInvocationHandler.invoke(SharedEntityManagerCreator.java:418) at jdk.proxy3.$Proxy328.getSingleResult(Unknown Source) at org.springframework.data.jpa.repository.query.JpaQueryExecution$SingleEntityExecution.doExecute(JpaQueryExecution.java:223) at org.springframework.data.jpa.repository.query.JpaQueryExecution.execute(JpaQueryExecution.java:92) at org.springframework.data.jpa.repository.query.AbstractJpaQuery.doExecute(AbstractJpaQuery.java:152) at org.springframework.data.jpa.repository.query.AbstractJpaQuery.execute(AbstractJpaQuery.java:140) at org.springframework.data.repository.core.support.RepositoryMethodInvoker.doInvoke(RepositoryMethodInvoker.java:170) at org.springframework.data.repository.core.support.RepositoryMethodInvoker.invoke(RepositoryMethodInvoker.java:158) at org.springframework.data.repository.core.support.QueryExecutorMethodInterceptor.doInvoke(QueryExecutorMethodInterceptor.java:164) at org.springframework.data.repository.core.support.QueryExecutorMethodInterceptor.invoke(QueryExecutorMethodInterceptor.java:143) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:184) at org.springframework.data.projection.DefaultMethodInvokingMethodInterceptor.invoke(DefaultMethodInvokingMethodInterceptor.java:70) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:184) at org.springframework.transaction.interceptor.TransactionInterceptor$1.proceedWithInvocation(TransactionInterceptor.java:123) at org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:392) at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:119) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:184) at org.springframework.dao.support.PersistenceExceptionTranslationInterceptor.invoke(PersistenceExceptionTranslationInterceptor.java:138) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:184) at org.springframework.data.jpa.repository.support.CrudMethodMetadataPostProcessor$CrudMethodMetadataPopulatingMethodInterceptor.invoke(CrudMethodMetadataPostProcessor.java:136) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:184) at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:97) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:184) at io.opentelemetry.javaagent.instrumentation.spring.data.v1_8.SpringDataInstrumentationModule$RepositoryInterceptor.invoke(SpringDataInstrumentationModule.java:112) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:184) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:223) at

Hope this information helps to find a good solution.

[trask]

related: open-telemetry/semantic-conventions#1536

[steverao]

There is a PR #12879 that fixed it.