Background worker send fails if ActiveRecord defined but not correctly configured

[Jerph]

Issue Description

Our rails app doesn't yet use ActiveRecord::Base for anything, but has some code that relies on the ActiveRecord library. In dev/test we have basically the default database.yml file with sqlite for dev/test, but production had a misconfiguration (e.g. database: '').

Since we never call ActiveRecord::Base explicitly in production it never caused exceptions. Sentry messages were silently failing to send in production, but worked in dev. If I set config.background_worker_threads = 0, it would work in production.

The issue appears to be this code from sentry-rails:

module Sentry
  class BackgroundWorker
    def perform(&block)
      @executor.post do
        # make sure the background worker returns AR connection if it accidentally acquire one during serialization
        ActiveRecord::Base.connection_pool.with_connection do
          block.call
        end
      end
    end
  end
end

When I correctly configured the dummy sqlite connection, it worked in production.

Reproduction Steps

Default sentry-rails install with a misconfigured database.yml:

# sentry.rb
Sentry.init do |config|
  config.dsn = ENV["SENTRY_DSN"]
  config.breadcrumbs_logger = [:active_support_logger, :http_logger]
  config.traces_sample_rate = 1.0
end

# database.yml
development:
  adapter: sqlite3
  # database: db/development.sqlite3
  # Bad configuration
  database: ''
  pool: 5
  timeout: 5000

Call Sentry.capture_message("test")

Expected Behavior

"Test" message captured OR log or inline message explaining where it failed.

Actual Behavior

No message at sentry.io. With sentry debug turned on, there are no indications of failure.

Ruby Version

2.6.8

SDK Version

4.8.0

Integration and Its Version

Rails

Sentry Config

Sentry.init do |config|
  config.dsn = "https://abcd@o71791.ingest.sentry.io/1234"
  config.breadcrumbs_logger = [:active_support_logger, :http_logger]
  config.traces_sample_rate = 1.0
end

[st0012]

@Jerph thanks for reporting this. I think the SDK should log the errors happened in the background worker. I will open a PR for it shortly.