Affects: 5.3.3
The issue was originally reported for Spring Cloud Sleuth but it seems it is not a Sleuth issue (and I can't transfer issues across orgs) so I'm opening this one to track it at the right place.
The original issue is this: https://github.com/spring-cloud/spring-cloud-sleuth/issues/1729 opened by @sting2804 It contains the details to understand what is going on, a sample project that reproduces the issue and some investigation details. The issue is very similar to https://github.com/spring-cloud/spring-cloud-sleuth/issues/1660
Description
When an exception is thrown from a method annotated with @Scheduled
all tracing information is lost when it reaches the error handler and error logs do not contain tracing information.
Sample: https://github.com/jonatan-ivanov/sleuth-gh-1729
Investigation details: https://github.com/spring-cloud/spring-cloud-sleuth/issues/1729#issuecomment-750448639 (also see spring-cloud/spring-cloud-sleuth#1660) Possible fix (breaking change): should be similar to https://github.com/spring-projects/spring-amqp/pull/1287
Comment From: StevenJDH
I experienced the same recently in a Spring Cloud project. I am using a method annotated with an @SqsListener
. The message is received correctly, and you can see the traceid and spanid, but if an uncaught exception is thrown by a service class processing this message, both of these ids are gone. The thread name handling all of this is simpleMessageListenerContainer. I even tried injecting the tracer class and setting the MDC from this thread with these ids, but they aren't present. I'm using Spring Cloud 2021.0.6/Spring Boot 2.7.10 with Sleuth 3.1.7. The scenario is different, but the result seems to be very similar as the issue being reported, so it sounds related.
Comment From: bclozel
We've instrumented @Scheduled
methods in #29883 and we faced the same limitation: in order to instrument those methods, we need to wrap the Runnable
and create new observations for each run. The error handler lives in a different part of the infrastructure and we cannot easily extend the scope of the observation up to the error handler unfortunately.
I'm declining this enhancement as a result. We will reopen this issue if we find another way to achieve that during the 6.1 milestones.
Comment From: TheBestPessimist
Can you please update the documentation to mention this very important aspect about @Scheduled
?
I lost a great number of hours debugging for what appears to be a trivial solution. (try catch throwable as the first statement in the scheduled task).
Comment From: antspk
Is there any follow-up discussion on this issue?
Comment From: bclozel
@antspk not really. What are you looking for?
Comment From: antspk
I believe I'm facing this issue with Spring Boot 3.2.5, which seems to be using Spring 6.1.6. When an @Scheduled operation fails, the tracing information is not available in the error handler. I haven't been able to find any follow-up discussions or documentation regarding this issue. Are there any known workarounds or plans to address this? Apart from try/catch as the first statement?
Comment From: bclozel
My previous comment here https://github.com/spring-projects/spring-framework/issues/26533#issuecomment-1610199517 is still valid from my point of view. If you find another way to handle this better I can work on it.