Move fetching merge request counts to an async call

What does this MR do and why?

Before this change we would fetch the users merge request count on page load. However this query could be slow and cause 500 errors. With this change we will only use the count on page load if it has been previously cached, if it isn't cached we will fetch from the API which will then cache the value to be used on next visit.

This helps improve performance for everyone in that if the cache doesn't exist because of an action to a merge request that causes the count cache to be invalidated the next page visit will be faster as it won't need to do this query on page load.

References

#555533 (closed)

Screenshots or screen recordings

Before After

How to set up and validate locally

  • On a merge request that you are an assignee of as long as there are no reviewers assigned assign a new reviewer (This should invalidate the merge request count cache)
  • Reload the page
  • You should notice the merge request badge in the sidebar not being visible until after the fetch request finishes
  • On the next page load (as long as the cache doesn't get invalidate again) the count will be visible on page load.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Merge request reports

Loading