Calling `perform_inline` with Sidekiq job causes error in `set_span_data` because `enqueued_at` is nil.

[davidwessman]

Issue Description

• After upgrading to 5.22.0 we are getting errors in set_span_data when calling perform_inline

Reproduction Steps

In a Rails project with Sidekiq and sentry-sidekiq call Job.perform_inline

Expected Behavior

Run the job like normal

Actual Behavior

It throws error:

TypeError
nil can't be coerced into Float (TypeError)

 set_span_data(transaction, id: job["jid"], queue: queue, latency: ((Time.now.to_f - job["enqueued_at"]) * 1000).to_i, retry_count: job["retry_count"] || 0)

Ruby Version

3.3.5

SDK Version

5.22.0

Integration and Its Version

Rails 7.1.5, Sidekiq 7.3.6

Sentry Config

SENTRY_FILTER = %i[
  params...
]

Sentry.init do |config|
  StaticPlatform.sentry_environment.try do |sentry_environment|
    config.environment = sentry_environment
  end
  config.breadcrumbs_logger = [:active_support_logger, :http_logger]
  config.traces_sample_rate = StaticPlatform.sentry_traces_sample_rate
  config.profiles_sample_rate = StaticPlatform.sentry_profiles_sample_rate
  config.propagate_traces = StaticPlatform.sentry_propagate_traces?

  # https://docs.sentry.io/platforms/ruby/guides/rails/data-management/sensitive-data/#scrubbing-data
  filter = ActiveSupport::ParameterFilter.new(
    SENTRY_FILTER
  )

  # Allow us to raise a custom error for Sidekiq workers to be retried without reporting to Sentry
  config.excluded_exceptions += ["ApplicationWorker::RetryItError"]

  config.before_send = lambda do |event, hint|
    filtered_event = filter.filter(event.to_hash)

    exception = hint[:exception]

    if exception.is_a?(RestClient::ExceptionWithResponse)
      filtered_event[:contexts][:exception_response_body] = exception.http_body
    elsif exception.is_a?(Faraday::Error)
      filtered_event[:contexts][:exception_response_body] = exception.response.present? ? exception.response[:body] : exception.to_s
    end
    filtered_event
  end
end

[sl0thentr0py]

will fix, that's because of the new Cache module related span data, sorry!