Unrelated Sidekiq job runs being grouped in same trace

[nateberkopec]

Issue Description

I'm seeing across multiple unrelated apps/projects this behavior where Sidekiq jobs are being grouped into the same parent trace, even though the job runs are completely unrelated:

Project A:

Project B:

You end up getting traces that are days long:

I think this really messes with sampling, as now I can end up with massive traces from Sidekiq using tons and tons of spans, which means I have to decrease my sample rate overall to compensate, meaning I get less spans from web requests.

Reproduction Steps

Unsure at this point. I don't know how this behavior works in Sentry so I don't know how to repro.

I think this only happens when a Sidekiq job is run and a web request was not the parent (i.e. a job triggered by a cron). This

Expected Behavior

Unrelated job runs should not be grouped into the same transaction.

Actual Behavior

They are.

Ruby Version

Multiple

SDK Version

Multiple, but includes 5.22.1.

Integration and Its Version

No response

Sentry Config

Multiple, no common thread in the config AFAICT

[nateberkopec]

This feels related to #2446 but, since I'm seeing this in 5.22.1, clearly wasn't fixed by that PR.

[nateberkopec]

In the case of one app, it's using Heroku Scheduler to kick off jobs. The other's not on Heroku, not sure what's running jobs outside of the web context there.

It kind of feels like a job created from e.g. a rake task lacks a proper root.

[nateberkopec]

Would it help if I tried something like #2476 in the context of rake tasks? 🤔

[sl0thentr0py]

the fix in #2446 was only if you use Sidekiq::Cron
I agree we need a general trace injection config boolean.