Upgrade Sentry gem to 4.4.0

Changelog: changed
Issue: https://gitlab.com/gitlab-com/gl-infra/scalability/-/issues/849
MR: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/62387

Gemfile

@@ -305,7 +305,9 @@ gem 'gitlab-license', '~> 1.5'
 gem 'rack-attack', '~> 6.3.0'
 
 # Sentry integration
-gem 'sentry-raven', '~> 3.1'
+gem 'sentry-ruby', '~> 4.4.0'
+gem 'sentry-sidekiq', '~> 4.4.0'
+gem 'sentry-rails', '~> 4.4.0'
 
 # PostgreSQL query parsing
 gem 'pg_query', '~> 2.0.3'

Gemfile.lock

@@ -1170,8 +1170,18 @@ GEM
     selenium-webdriver (3.142.7)
       childprocess (>= 0.5, < 4.0)
       rubyzip (>= 1.2.2)
-    sentry-raven (3.1.2)
+    sentry-rails (4.4.0)
+      railties (>= 5.0)
+      sentry-ruby-core (~> 4.4.0.pre.beta)
+    sentry-ruby (4.4.2)
+      concurrent-ruby (~> 1.0, >= 1.0.2)
       faraday (>= 1.0)
+      sentry-ruby-core (= 4.4.2)
+    sentry-ruby-core (4.4.2)
+      concurrent-ruby
+      faraday
+    sentry-sidekiq (4.4.0)
+      sentry-ruby-core (~> 4.4.0.pre.beta)
     settingslogic (2.0.9)
     sexp_processor (4.15.1)
     shellany (0.0.1)
@@ -1620,7 +1630,9 @@ DEPENDENCIES
   sassc-rails (~> 2.1.0)
   seed-fu (~> 2.3.7)
   selenium-webdriver (~> 3.142)
-  sentry-raven (~> 3.1)
+  sentry-rails (~> 4.4.0)
+  sentry-ruby (~> 4.4.0)
+  sentry-sidekiq (~> 4.4.0)
   settingslogic (~> 2.0.9)
   shoulda-matchers (~> 4.0.1)
   sidekiq (~> 5.2.7)

lib/gitlab/error_tracking.rb

@@ -24,18 +24,20 @@ module Gitlab
 
     class << self
       def configure
-        Raven.configure do |config|
+        Sentry.init do |config|
           config.dsn = sentry_dsn
           config.release = Gitlab.revision
-          config.current_environment = Gitlab.config.sentry.environment
+          config.environment = Gitlab.config.sentry.environment
 
           # Sanitize fields based on those sanitized from Rails.
-          config.sanitize_fields = Rails.application.config.filter_parameters.map(&:to_s)
+          # config.sanitize_fields = Rails.application.config.filter_parameters.map(&:to_s)
 
           # Sanitize authentication headers
-          config.sanitize_http_headers = %w[Authorization Private-Token]
+          # config.sanitize_http_headers = %w[Authorization Private-Token]
           config.before_send = method(:before_send)
 
+          config.background_worker_threads = 0
+
           yield config if block_given?
         end
       end
@@ -108,8 +110,11 @@ module Gitlab
       def process_exception(exception, sentry: false, logging: true, extra:)
         context_payload = Gitlab::ErrorTracking::ContextPayloadGenerator.generate(exception, extra)
 
-        if sentry && Raven.configuration.server
-          Raven.capture_exception(exception, **context_payload)
+        # There is a possiblity that this method is called before Sentry is
+        # configured. Since Sentry 4.0, some methods of Sentry are forwarded to
+        # to `nil`, hence we have to check the client as well.
+        if sentry && ::Sentry.get_current_client && ::Sentry.configuration.dsn
+          ::Sentry.capture_exception(exception, **context_payload)
         end
 
         if logging

lib/gitlab/error_tracking/log_formatter.rb

@@ -3,7 +3,7 @@
 module Gitlab
   module ErrorTracking
     class LogFormatter
-      # Note: all the accesses to Raven's contexts here are to keep the
+      # Note: all the accesses to Sentry's contexts here are to keep the
       # backward-compatibility to Sentry's built-in integrations. In future,
       # they can be removed.
       def generate_log(exception, context_payload)
@@ -20,21 +20,27 @@ module Gitlab
       private
 
       def append_user_to_log!(payload, context_payload)
-        user_context = Raven.context.user.merge(context_payload[:user])
+        return if current_scope.blank?
+
+        user_context = current_scope.user.merge(context_payload[:user])
         user_context.each do |key, value|
           payload["user.#{key}"] = value
         end
       end
 
       def append_tags_to_log!(payload, context_payload)
-        tags_context = Raven.context.tags.merge(context_payload[:tags])
+        return if current_scope.blank?
+
+        tags_context = current_scope.tags.merge(context_payload[:tags])
         tags_context.each do |key, value|
           payload["tags.#{key}"] = value
         end
       end
 
       def append_extra_to_log!(payload, context_payload)
-        extra = Raven.context.extra.merge(context_payload[:extra])
+        return if current_scope.blank?
+
+        extra = current_scope.extra.merge(context_payload[:extra])
         extra = extra.except(:server)
 
         # The extra value for sidekiq is a hash whose keys are strings.
@@ -50,6 +56,10 @@ module Gitlab
           payload["extra.#{key}"] = value
         end
       end
+
+      def current_scope
+        Sentry.get_current_scope
+      end
     end
   end
 end

lib/gitlab/error_tracking/processor/grpc_error_processor.rb

@@ -17,8 +17,7 @@ module Gitlab
           # Sentry can report multiple exceptions in an event. Sanitize
           # only the first one since that's what is used for grouping.
           def process_first_exception_value(event)
-            # Better in new version, will be event.exception.values
-            exceptions = event.instance_variable_get(:@interfaces)[:exception]&.values
+            exceptions = event.exception&.instance_variable_get(:@values)
 
             return unless exceptions.is_a?(Array)
 
@@ -33,9 +32,7 @@ module Gitlab
 
             message, debug_str = split_debug_error_string(raw_message)
 
-            # Worse in new version, no setter! Have to poke at the
-            # instance variable
-            exception.value = message if message
+            exception.instance_variable_set(:@value, message) if message
             event.extra[:grpc_debug_error_string] = debug_str if debug_str
           end
 
@@ -66,7 +63,7 @@ module Gitlab
 
           def valid_exception?(exception)
             case exception
-            when Raven::SingleExceptionInterface
+            when Sentry::SingleExceptionInterface
               exception&.value
             else
               false