Tracing information is missing when Exception is thrown from Scheduled methods

[jonatan-ivanov]

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: spring-cloud/spring-cloud-sleuth#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 spring-cloud/spring-cloud-sleuth#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: spring-cloud/spring-cloud-sleuth#1729 (comment) (also see spring-cloud/spring-cloud-sleuth#1660)
Possible fix (breaking change): should be similar to spring-projects/spring-amqp#1287

[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.

[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.

[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).

[antspk]

Is there any follow-up discussion on this issue?

[bclozel]

@antspk not really. What are you looking for?

[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?

[bclozel]

My previous comment here #26533 (comment) is still valid from my point of view. If you find another way to handle this better I can work on it.