Repository navigation
fix(sidekiq): Start a new trace for each sidekiq-scheduler enqueue - #3159
Merged
Merged
Conversation
Jobs enqueued by sidekiq-scheduler all continued the scheduler thread's long-lived propagation context, so every scheduled job in a process shared one trace_id and, since 6.0, one sample_rand (an all-or-nothing sampling decision per boot). Wrap SidekiqScheduler::Scheduler#enqueue_job in a fresh hub, scope and transaction, mirroring the sidekiq-cron patch. Fixes #3144 Co-Authored-By: Neel Shah <6536764+sl0thentr0py@users.noreply.github.com>
sl0thentr0py
force-pushed
the
fix/sidekiq-scheduler-fresh-trace
branch
from
October 27, 2026 13:22
d38abad to
012a303
Compare
sl0thentr0py
approved these changes
Oct 27, 2026
|
Thanks for the work on this! Do you know when this change is expected to be included in a release? |
Member
|
@Trolorol will likely release by tomorrow |
3 tasks done
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Jobs enqueued by sidekiq-scheduler all reuse the propagation context of the scheduler's long-lived thread. Every scheduled job in a process therefore shares one
trace_id. Since 6.0 (propagatedsample_rand, #2671) they also share onesample_rand, so with a sample rate of 0.5 each boot traces either all scheduled runs or none of them.This wraps
SidekiqScheduler::Scheduler#enqueue_jobthe same waySentry::Sidekiq::Cron::Jobwrapsenqueue!(#2446). It clones the hub, opens a fresh scope and starts a transaction (op: queue.sidekiq-scheduler,origin: auto.queue.sidekiq.scheduler) named after the job class. Each scheduled run gets its own trace and sampling decision, and the job'squeue.publishspan is recorded under that transaction.The change lives in the existing opt-in
:sidekiq_schedulerpatch.enqueue_jobalso handles manual enqueues, such as "Enqueue now" in the sidekiq-scheduler web UI, so those get a fresh trace too.Verification
spec/sentry/sidekiq-scheduler/scheduler_spec.rbcheck thatenqueue_jobproduces a transaction with aqueue.publishspan. They also check that two enqueues get differenttrace_ids andsample_rands in the job's propagation headers. Both specs fail without the fix and pass with it.sentry-sidekiqsuite passes onruby-3.4_sidekiq-7.0(sidekiq-scheduler 5.0) andruby-3.4_sidekiq-8.0.0(sidekiq-scheduler 6.0): 80 examples, 0 failures.traces_samplerreturning 0.5. Before the fix, each boot had exactly one trace_id and one sample_rand, so sampling was all-or-nothing. With this branch, every job got its own trace and sampling was mixed within each boot (3/7, 5/7 and 2/7 sampled).via @sl0thentr0py.
--
View Junior Session [Sentry]