ObserverExceptionHandler for non async observers

Description

I am facing a production issue right now, where all my log says is:

Failure occurred while notifying a transational Observer [method=observerMethod()] for event of type CustomType
- please enable debug logging to see the full stack trace

(I removed the FQCN, and replaced them with placeholders).

The above log is obiously not enough to figure out what the original exception was. Was it a TimeoutException while publishing to RabbitMQ, or was it a LazyInitException from some hibernate entity? The range of possibilities is simply to wide figure it out with this limited information.

I am not going to activate debug logging on the production system every time I face this issue. I need a solution which I configure once, and it just works. Also, how it is implemented right now, this would lead to 2 lines logged. One error (the one above), and one debug. The debug logs are not going into our usual monitoring solution - I would need to see the logs on the prod system.

This is where the logging is happening: https://github.com/quarkusio/quarkus/blob/ef43e2a95e48828fee2cf5f1990ebca48ea7a96d/independent-projects/arc/runtime/src/main/java/io/quarkus/arc/impl/EventImpl.java#L473-L480

For Async Observers, I found AsyncObserverExceptionHandler, which allows to modify how their exceptions are logged: https://quarkus.io/guides/cdi-reference#exceptions-thrown-by-an-asynchronous-observer-method

For normal Observers, can either:

• the exception always be logged. Because what is someone going to do without it?
• or an ObserverExceptionHandler be added, which would allow me to configure logging to my needs?

Implementation ideas

No response

[manovotn]

Looking some more into the original issue, I think the reason might have been to reduce the noise from observer methods that can (deliberately?) sometimes throw an exception. It looks like @famod and @gsmet both commented in favor of that, see https://github.com/quarkusio/quarkus/pull/23944.

I don’t remember but we should at least log the exception cause as Weld does.

I agree. I wouldn’t even mind showing the whole error but due to the above, I don’t think I’ll get by with that 😃 Anyhow, I’ll send a PR that at least improves it.

[mkouba]

I agree. I wouldn’t even mind showing the whole error but due to the above, I don’t think I’ll get by with that 😃

The root cause class and exception message should be enough.