Skip to content

N+1 queries in NotificationRecipientService

From https://gitlab.com/gitlab-org/gitlab-ce/issues/45526, we see that NotificationRecipientService has a number of N+1 queries, particularly when retrieving notification settings from each participant:

notification-service.txt

QueryRecorder reveals this with this spec:

require 'spec_helper'

describe NotificationRecipientService do
  let(:service) { described_class }
  let(:assignee) { create(:user) }
  let(:project) { create(:project, :private) }

  describe '#build_new_note_recipients' do
    let(:issue) { create(:issue, project: project, assignees: [assignee]) }
    let(:note) { create(:note_on_issue, noteable: issue, project_id: issue.project_id) }

    def create_participant
      participant = create(:user)
      project.add_master(participant)
      issue.subscriptions.create(user: participant, project: project, subscribed: true)
    end

    it 'avoids N+1 queries' do
      create_participant

      service.build_new_note_recipients(note)

      control_count = ActiveRecord::QueryRecorder.new do
        service.build_new_note_recipients(note)
      end

      create_participant

      expect { service.build_new_note_recipients(note) }.not_to exceed_query_limit(control_count)
    end
  end
end

Results:

  1) NotificationRecipientService#build_new_note_recipients avoids N+1 queries
     Failure/Error: expect { service.build_new_note_recipients(note) }.not_to exceed_query_limit(control_count)

       Expected a maximum of 18 queries, got 23:

       Extra queries:

       [2] SELECT "notification_settings"."user_id" FROM "notification_settings" WHERE "notification_settings"."level" = $1 AND "notification_settings"."user_id" IN (5, 1, 2) AND "notification_settings"."source_type" IS NULL

       [1] SELECT  "users".* FROM "users" WHERE "users"."id" = $1 LIMIT 1

       [1] SELECT "notification_settings".* FROM "notification_settings" WHERE "notification_settings"."user_id" IN (1, 5)

       [2] SELECT  1 AS one FROM "users" INNER JOIN "project_authorizations" ON "users"."id" = "project_authorizations"."user_id" WHERE "project_authorizations"."project_id" = $1 AND "users"."id" = $2 LIMIT 1

       [1] SELECT  1 AS one FROM "users" INNER JOIN "issue_assignees" ON "users"."id" = "issue_assignees"."user_id" WHERE "issue_assignees"."issue_id" = $1 AND "users"."id" = $2 LIMIT 1

       [1] SELECT  "subscriptions".* FROM "subscriptions" WHERE "subscriptions"."subscribable_id" = $1 AND "subscriptions"."subscribable_type" = $2 AND "subscriptions"."user_id" = $3 LIMIT 1

The issue here is that Participable#raw_participants builds a set of users and doesn't provide a way to preload attributes.