Jobs created by Sidekiq-cron shouldn’t propagate trace header

[frederikspang]

Issue Description

Currently when sidekiq-cron enqueues jobs, trace headers are added, leaving a Long running trace with several unrelated jobs, and no root transaction.

This should be patched in Sentry-sidekiq to reset the trace id for sidekiq cron when sidekiq-cron patch is enabled

Reproduction Steps

Run app
Enqueue job every x minute
Find trace (or follow from an error in Issues tab)
See duration is several hours and without root transaction.

Expected Behavior

Each enqueued job from sidekiq cron is unrelated and with different trace IDs.

Actual Behavior

All enqueued jobs (per process/sidekiqCron Thread) are with same trace id.

Ruby Version

3.3.4

SDK Version

master

Integration and Its Version

Sidekiq

Sentry Config

No response

[sl0thentr0py]

true, this is also how we do it in celery beat, will fix!

[frederikspang]

Could it be something as simple as:

def enque!(*)
  # make sure the current thread has a clean hub
  Sentry.clone_hub_to_current_thread

  Sentry.with_scope do |scope|
    Sentry.with_session_tracking do
      super
    end
  end
end

Obviously, I don't know how it's done in Celery - But the one above is inspired by the Rack middleware - Except the patching of enque! method from Sidekiq cron.

[grk]

There's a similar issue with clockwork - everything scheduled from the clockwork process inherits one huge trace. Ideally there should be an api to do something like

Sentry.without_trace_propagation do
  SomeJob.perform_async
end

[frederikspang]

Giving this a go currently.

There is a slight dependency on #2403

If I get this right, there should be a root transaction, that is the enqueuing from sidekiq-cron in one thread; That should probably be queue.publish, for this.

Would you be OK with a partial implementation, that depends on #2403 before merging? @sl0thentr0py @solnic

[sl0thentr0py]

hey, I will ask @solnic to follow up here once he's back next week

[solnic]

Would you be OK with a partial implementation, that depends on #2403 before merging? @sl0thentr0py @solnic

@frederikspang yes thank you, just open a PR and we can take it from there!