Skip to content

Cache finder count_by_state when no filters set [RUN ALL RSPEC] [RUN AS-IF-FOSS]

What does this MR do?

Related to #325656 (closed)

Every time we load issuables list pages we populate the counts in the state tabs. This is an expensive COUNT query that could be cached when the list doesn't include filters, to improve performance.

If the user performs a search or filters the results, the counts will be re-calculated to reflect the new counts. Because of this, the performance improvement will be limited to the first page-load or any navigation without filters.

The cache will expire every 1 hour.

Given that the method that calculates the issuable state counts is defined in IssuableFinder, we need to handle the different cases by using multiple cache keys:

  • Merge Requests in a project
  • Merge Requests in a group
  • Issues with public access in a project
  • Issues with public access in a group
  • Issues with public, limited and confidential access in a project
  • Issues with public, limited and confidential access in a group
  • Epics with public access in a group
  • Epics with public, limited and confidential access in a group

Every key will contain counts stored as a hash, eg {"opened"=>2, "closed"=>1, "all"=>3}.

This implementation is behind the FF cached_issuable_count_by_state (enabled by default).

Screenshots (strongly suggested)

Does this MR meet the acceptance criteria?

Conformity

Availability and Testing

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

  • Label as security and @ mention @gitlab-com/gl-security/appsec
  • The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
  • Security reports checked/validated by a reviewer from the AppSec team

Related to #325656 (closed)

Edited by Eugenia Grieff

Merge request reports

Loading