Add incidents and comments finders for status page
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
Parameters used for these plans:
-
project_id: 278964
- https://gitlab.com/gitlab-org/gitlab -
issue_id: 30998761
- #207181 (closed)
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
✅ 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
❗ 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
❗ 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
- [-] Changelog entry
- [-] Documentation (if required)
-
Code review guidelines -
Merge request performance guidelines -
Style guides - [-] Database guides
-
Separation of EE specific content
Availability and Testing
- [-] Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process.
- [-] Tested in all supported browsers
- [-] Informed Infrastructure department of a default or new setting change, if applicable per definition of done
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