feat(active_job): support for tracing

[solnic]

This branch extends Sentry's ActiveJob instrumentation so distributed tracing works across Resque, DelayedJob, and Sidekiq. Instead of per-adapter integrations, tracing is now driven through a single common ActiveJob extension (Sentry::Rails::ActiveJobExtensions), which hooks serialize / deserialize / perform_now to:

• emit a producer span on enqueue,
• propagate trace context (and, with PII enabled, an allowlisted user context) through the job payload under a single _sentry key,
• record messaging span data on the consumer transaction,
• isolate the Sentry hub per worker thread.

Because the behavior lives in one extension, every adapter is verified against the same set of shared AJ specs — adding a new adapter is just a context + a one-line it_behaves_like.

New config

config.rails.active_job_propagate_traces (default true) gates trace propagation through the job payload.

New shared specs

A spec wires up the shared backend harness, an adapter-specific context, and the shared example groups.

Resque:

RSpec.describe "Sentry + ActiveJob on the resque adapter", type: :job do
  include ActiveSupport::Testing::TimeHelpers
  include_context "active_job backend harness", adapter: :resque
  include_context "resque adapter"

  it_behaves_like "a Sentry-instrumented ActiveJob backend"
  it_behaves_like "an ActiveJob backend that supports distributed tracing"
end

Sidekiq:

RSpec.describe "Sentry + ActiveJob on the sidekiq adapter", type: :job do
  include_context "active_job backend harness", adapter: :sidekiq
  include_context "sidekiq adapter"

  it_behaves_like "a Sentry-instrumented ActiveJob backend"
  it_behaves_like "an ActiveJob backend that supports distributed tracing"
end

The "...supports distributed tracing" shared example is itself a meta-group that pulls in the individual checks, so each adapter gets full coverage for free:

RSpec.shared_examples "an ActiveJob backend that supports distributed tracing" do
  it_behaves_like "an ActiveJob backend that emits a producer span on enqueue"
  it_behaves_like "an ActiveJob backend that propagates trace context through the job payload"
  it_behaves_like "an ActiveJob backend that records messaging span data on the consumer transaction"
  it_behaves_like "an ActiveJob backend that propagates Sentry user context through job payloads"
  it_behaves_like "an ActiveJob backend that isolates Sentry context per worker thread"
end

E2E coverage

This branch add more E2E specs (spec/features/active_job_tracing_spec.rb) that exercises the full path: the Svelte mini app's "Trigger Job" button fetches POST /jobs on the Rails mini app, the browser SDK propagates sentry-trace + baggage, and we assert that the browser fetch, the controller http.server transaction, the queue.publish producer span, and the queue.active_job consumer transaction all share one trace (consumer parented on the publish span, matching messaging.message.id).

To support worker-based adapters, spec/apps/rails-mini/worker.rb boots the same Rails + Sentry app in a separate process and runs the job through whichever adapter SENTRY_E2E_ACTIVE_JOB_ADAPTER selects (:async/:inline in-process, or a real worker for :sidekiq, :resque, :delayed_job) — so the same e2e assertions run across adapters via the CI matrix.

Screenshots

Distributed tracing works OOTB now with any Active Job adapter 🎉

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

Want reviews to match your repository better? Bugbot Learning can learn team-specific rules from PR activity. A team admin can enable Learning in the Cursor dashboard.

^{Reviewed by Cursor Bugbot for commit 332bf25. Configure here.}

[sentry]

Bug: The exception handling in record_producer_span may re-raise Sentry-internal errors that occur after a job is successfully enqueued, potentially crashing the enqueue process.
_{Severity: LOW}

Suggested Fix

Refine the exception handling to be more specific. Instead of a broad raise if enqueued, only re-raise exceptions that occur before the enqueue.call is executed. This can be achieved by moving run_enqueue.call outside the begin/rescue block for Sentry operations or by using a more granular flagging system to distinguish between pre-enqueue and post-enqueue Sentry errors.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.

Location: sentry-rails/lib/sentry/rails/active_job.rb#L108-L113

Potential issue: In `record_producer_span`, the exception handling logic is too broad.
If an error occurs within Sentry's internal `with_child_span` method *after* the job has
been successfully enqueued (for example, during span finalization), the `rescue` block
will catch it. However, because the `enqueued` flag is already true, the condition
`raise if enqueued` will re-raise the exception. This violates the intended behavior of
preventing Sentry-internal errors from crashing the job enqueue process, potentially
causing the application to fail to enqueue a job that was otherwise successfully
processed.

_{Did we get this right? 👍 / 👎 to inform future reviews.}