ongoing span relationships with jobs that repeat jobs

[randallt]

It seems questionable to propagate the parent span to jobs (callables and runnables) that repeat forever. This leads to traces that never close.

I have a use case where a first-access causes a scheduled job to be created 'scheduleAtFixedRate' or 'scheduleWithFixedDelay'. This is a repeated job, as such, it should not be associated with the parent span that initially caused it to be scheduled.

This behavior is in the TracedScheduledExecutorService class. I would suggest that inclusion of the these 'rules' be opt-in, not by default.

I'm curious what the use case is of associating a repeating job with a parent span, as I can't think of one immediately...

[yurishkuro]

Using instrumented executors for running futures and async callbacks is way more frequent use case than background jobs. Background jobs can explicitly clear the context.

[randallt]

Exactly.

I'm not saying to not instrument the one-time futures and async callbacks. Those indeed are the primary need here.

I'm arguing that the 'scheduleAtFixedRate' or 'scheduleWithFixedDelay' methods (which are used to create background jobs) should not be instrumented by default here--at least not using the currently active span as their parent.