Track and act upon the number of executed queries

This ensures that we have more visibility in the number of SQL queries
that are executed in web requests. The current threshold is hardcoded to
100 as we will rarely (maybe once or twice) change it.

In production and development we use Sentry if enabled, in the test
environment we raise an error. This feature is also only enabled in
production/staging when running on GitLab.com as it's not very useful to
other users.

1 files changed, 36 insertions, 0 deletions

diff --git a/lib/gitlab/query_limiting.rb b/lib/gitlab/query_limiting.rb
new file mode 100644
index 00000000000..f64f1757144
--- /dev/null
+++ b/lib/gitlab/query_limiting.rb
@@ -0,0 +1,36 @@
+module Gitlab
+  module QueryLimiting
+    # Returns true if we should enable tracking of query counts.
+    #
+    # This is only enabled in production/staging if we're running on GitLab.com.
+    # This ensures we don't produce any errors that users can't do anything
+    # about themselves.
+    def self.enable?
+      Gitlab.com? || Rails.env.development? || Rails.env.test?
+    end
+
+    # Allows the current request to execute any number of SQL queries.
+    #
+    # This method should _only_ be used when there's a corresponding issue to
+    # reduce the number of queries.
+    #
+    # The issue URL is only meant to push developers into creating an issue
+    # instead of blindly whitelisting offending blocks of code.
+    def self.whitelist(issue_url)
+      return unless enable_whitelist?
+
+      unless issue_url.start_with?('https://')
+        raise(
+          ArgumentError,
+          'You must provide a valid issue URL in order to whitelist a block of code'
+        )
+      end
+
+      Transaction&.current&.whitelisted = true
+    end
+
+    def self.enable_whitelist?
+      Rails.env.development? || Rails.env.test?
+    end
+  end
+end