Avoid scheduling Remote Mirror updates if an update was already scheduled

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

• Close this issue

Right now, we schedule a new UpdateRemoteMirrorWorker for each update we get. If an update was recently started, we schedule it a little bit in the future, so the currently running one can finish first. If another update happens before the the job scheduled in the future runs, then we'll schedule another one a little bit further in the future.

Those last jobs become no-ops, since when the first push mirror runs, it will already have included the changes.

We should avoid scheduling these no-op jobs. We could do this by keeping track of the jid if we schedule a job in the future, then we can check the status of that job to determine if we need to schedule another job.

---

The following discussion from gitlab-ce!31247 should be addressed:

• @reprazent started a discussion:

  This could still be optimized: If we keep track of the jid that was scheduled and check if it's still appropriate before scheduling anything, we could avoid scheduling multiple no-op jobs.

  But I'd rather deal with that in a separate issue.