Open michalcukierman opened 1 month ago
Hi @michalcukierman, I've had this at the back of my mind, and had time to have a quick look.
For incoming messages this is not applicable. Because before the consuming method is called, "consume" span has already been closed. And for deserialization errors, the span has not been created yet.
As for processing errors, if the method is annotated with @WithSpan
, this is already captured and span is finished with an exception.
For outgoing messages, maybe we can do something. I think we end the span without waiting for the message acknowledgement. We may wait for the message delivery ack to end the span.
It appears that attaching exceptions to spans in error handlers could be implemented relatively easily, improving the observability of failures.
The approach taken in the Quarkus handler (AttachExceptionHandler) uses the following line to record exceptions:
We could adopt a similar approach in PulsarIncomingChannel to enhance traceability. For example, modifying the method here: smallrye-reactive-messaging-pulsar/PulsarIncomingChannel.java#L199:
Adding this simple modification would provide a more comprehensive view of exceptions for observability tools like OpenTelemetry, Jaeger, or similar, enabling better tracking and debugging of issues across the system.
I can create the PR, if you think that the investigation is correct.