You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We want to use the @Transactional annotation in order to have one transaction by Query or Mutation. We added this annotation to a custom AsyncExecutionStrategy.
It works fine except for some exceptions, for example : NonNullableFieldWasNullException. This exception is not logged, it is only visible in the GraphQL response. Without the transactional annotation we have the correct response containing the error. But with the transactional annotation we didn't, an UnexpectedRollbackException is thrown. In this case the error is not logged and we have no idea of what is wrong.
We push a repository to reproduce the problem : https://github.com/viico/unexpectedrollbackexception. You can clone it, the class ProjectQueryResolverTest contains a test which should pass. It passes if we comment the transactional annotation (line 19 of TransactionalAsyncExecutionStrategyWithExceptionHandler class).
In the repo the exception NonNullableFieldWasNullException is thrown because we have a null field (label) which must not be null in the GrapQL schema.
For people who have the same problem : we have a workaround, you can log the error before UnexpectedRollbackException is thrown. The problem is still here but you have a log with the correct error, you can add the log in the custom AsyncExecutionStrategy :
Spring's transaction management rolls back transactions whenever it sees an unexpected exception. By default, that is every exception.
You can declare certain exceptions to be considered fine, in your case that would be @Transactional(noRollbackFor = NonNullableFieldWasNullException.class).
Spring's transaction management isn't aware of which exceptions are fine and what exceptions should lead to a rollback.
Thanks for your response. We will declare exceptions to be considered fine.
One last question : is it normal that this exception is not logged ?
When this exception is thrown, there is nothing on server side to trace the exception. That was the main problem for us because the server response was difficult to have : so even if we not rollback we will continue to log the exception (describe in my code block); just to know what happen.
The exception is caught and handled in GraphQL Java. You have the reason for the failure in the response, and I presume that's why the exception is not logged, but in any case it's up to GraphQL Java.
We want to use the
@Transactional
annotation in order to have one transaction byQuery
orMutation
. We added this annotation to a customAsyncExecutionStrategy
.It works fine except for some exceptions, for example :
NonNullableFieldWasNullException
. This exception is not logged, it is only visible in the GraphQL response. Without the transactional annotation we have the correct response containing the error. But with the transactional annotation we didn't, anUnexpectedRollbackException
is thrown. In this case the error is not logged and we have no idea of what is wrong.We push a repository to reproduce the problem : https://github.com/viico/unexpectedrollbackexception. You can clone it, the class ProjectQueryResolverTest contains a test which should pass. It passes if we comment the transactional annotation (line 19 of TransactionalAsyncExecutionStrategyWithExceptionHandler class).
In the repo the exception
NonNullableFieldWasNullException
is thrown because we have a null field (label) which must not be null in the GrapQL schema.For people who have the same problem : we have a workaround, you can log the error before
UnexpectedRollbackException
is thrown. The problem is still here but you have a log with the correct error, you can add the log in the customAsyncExecutionStrategy
:The text was updated successfully, but these errors were encountered: