Skip to content

Add incidents and comments finders for status page

Peter Leitzen requested to merge pl-status-page-mvc-finder into master

What does this MR do?

Part of #205168 (closed).

This MR implements specialized finders used to load issues and notes which will be published as incidents and comments to the status page.

This MR is behind a beta feature flag and we tracking the rollout in #210026 (closed).

Note, although a feature we don't provide a changelog entry as these changes are not user-facing. These finders are used in the follow-up MR !26785 (merged).

database query plans

⚠ All SQL queries below will be executed in a background job and not during a web request.

Parameters used for these plans:

StatusPage::IncidentsFinder#find_by_id

Click to expand

Query:

SELECT "issues".*
  FROM "issues"
  WHERE "issues"."confidential" = FALSE AND "issues"."project_id" = 278964 AND "issues"."id" = 30998761
LIMIT 1

Plan: https://explain.depesz.com/s/95DF

Recommendations:

✅ Looks good

StatusPage::IncidentsFinder#all(limit: 20)

Click to expand

Query:

SELECT "issues".*
  FROM "issues"
  WHERE "issues"."confidential" = FALSE AND "issues"."project_id" = 1
ORDER BY "issues"."created_at" DESC
LIMIT 20

Plan: https://explain.depesz.com/s/3Y9z

Recommendations:

❗ Specialized index needed – The index(es) currently used does not serve quite well for the needs of this query (notice Rows Removed by Filter: ..., meaning that the index fetched many non-target rows). Consider adding more specialized index(es).

StatusPage::IncidentCommentsFinder#all(limit: 100)

Click to expand

Query:

SELECT "notes".* 
  FROM "notes"
  INNER JOIN "award_emoji" ON "award_emoji"."awardable_id" = "notes"."id" AND "award_emoji"."awardable_type" = 'Note'
  WHERE "notes"."noteable_id" = 526 AND "notes"."noteable_type" = 'Issue' AND "notes"."system" = FALSE AND "award_emoji"."name" = 'microphone' 
ORDER BY "notes"."created_at" ASC, "notes"."id" ASC
LIMIT 100

Plan: https://explain.depesz.com/s/oEKC

Recommendations:

❗ Query processes too much data to return a relatively small number of rows. – Reduce data cardinality as early as possible during the execution, using one or several of the following techniques: new indexes, partitioning, query rewriting, denormalization. See the visualization of the plan to understand which plan nodes are the main bottlenecks.

❗ Specialized index needed – The index(es) currently used does not serve quite well for the needs of this query (notice Rows Removed by Filter: ..., meaning that the index fetched many non-target rows). Consider adding more specialized index(es).

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
Edited by Peter Leitzen

Merge request reports