Only read rebase status from the model

Prior to 12.1, rebase status was looked up directly from Gitaly. In
https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/14417 , a DB
column was added to track the status instead. However, we couldn't stop
looking at the gitaly status immediately, since some rebases may been
running across the upgrade.

Now that we're in 12.3, it is safe to remove the direct-to-gitaly
lookup. This also happens to fix a 500 error that is seen when viewing
an MR for a fork where the source project has been removed.

We still look at the Gitaly status in the service, just in case Gitaly
and Sidekiq get out of sync - I assume this is possible, and it's a
relatively cheap check.

Since we atomically check and set `merge_requests.rebase_jid`, we
should never enqueue two `RebaseWorker` jobs in parallel.

1 files changed, 1 insertions, 12 deletions

diff --git a/app/models/merge_request.rb b/app/models/merge_request.rb
index 4306dd9266f..bfd636fa62a 100644
--- a/app/models/merge_request.rb
+++ b/app/models/merge_request.rb
@@ -220,18 +220,7 @@ class MergeRequest < ApplicationRecord
   end
 
   def rebase_in_progress?
-    (rebase_jid.present? && Gitlab::SidekiqStatus.running?(rebase_jid)) ||
-      gitaly_rebase_in_progress?
-  end
-
-  # TODO: remove the Gitaly lookup after v12.1, when rebase_jid will be reliable
-  def gitaly_rebase_in_progress?
-    strong_memoize(:gitaly_rebase_in_progress) do
-      # The source project can be deleted
-      next false unless source_project
-
-      source_project.repository.rebase_in_progress?(id)
-    end
+    rebase_jid.present? && Gitlab::SidekiqStatus.running?(rebase_jid)
   end
 
   # Use this method whenever you need to make sure the head_pipeline is synced with the