[Feature flag Rollout] homepage_merge_requests_widget -- merge requests widget on the personal homepage

Summary

Roll out the feature currently behind the homepage_merge_requests_widget feature flag.

Note

Process and guidance live in the docs — this issue is just the commands and a place to track the rollout. "Rolling out" means incrementally enabling the flag on GitLab.com to validate stability — it is not the same as releasing the feature, which happens when the flag is removed. Feature flag controls · Feature flag lifecycle

What could go wrong?

The widget is the slowest component on the homepage and introduces new risk patterns for this traffic-heavy page.

  • Load time is the primary risk. The HomepageMergeRequestsWidget query has a median latency of 1.055 seconds—over 2x the 0.43 seconds for other homepage widgets. The widget fetches up to 16 merge requests with per-MR metadata, where previous count cards selected only first: 1. Approvals are an N+1 pattern: roughly 47 of 75 SQL queries in the full request come from approvals (~3 per MR). The known fix is moving approvals to a second request, which the merge request list page already does.
  • Unbounded count queries. Both tab count badges select an unbounded count, costing two large COUNT queries for users with thousands of open merge requests.
  • The cost recurs. The widget refetches on every tab focus via the homepage's visibility handler, so latency is not a first-paint-only concern.
  • A pre-existing gap this amplifies. MergeRequestType.head_pipeline lacks a calls_gitaly: true declaration, but can trigger Gitaly calls when merge requests lack persisted diffs. The homepage will now select headPipeline for up to 16 merge requests per user, where nothing on the page did before. In production this only tracks to Sentry rather than raising, so the risk is error noise rather than broken rendering. Owned by the code_review_workflow group and not yet filed.

This is read-only rendering with no data-loss risk. Rollback is simply disabling the flag. Watch Rails request latency and database load on the homepage endpoints via https://dashboards.gitlab.net.

Events

Feature Flag events are only logged by default for feature flags marked for the current or future milestones. To enable while the feature flag is active, see https://docs.gitlab.com/development/feature_flags/#logging

Rollout

Run all production /chatops in #production and cross-post the results to #s_growth. Background: incremental rollout process, feature actors.

Non-production

/chatops gitlab run feature set homepage_merge_requests_widget 50 --actors --dev --pre --staging --staging-ref
/chatops gitlab run feature set homepage_merge_requests_widget true --dev --pre --staging --staging-ref

Production

Decision: enable directly at 100%, without a percentage ramp. The change is read-only rendering and is reverted by toggling the flag, which the docs treat as grounds for proceeding straight to enabled (simple, low-risk, easily reverted features). Verified working on staging on 2026-10-01.

Because there is no ramp, the post-enable check carries the weight: the widget has known latency costs (see What could go wrong?), so watch Rails request latency and database load on the homepage endpoints immediately after enabling — see verifying metrics after enabling a feature flag. Roll back with false if Apdex or database load degrades.

/chatops gitlab run feature set homepage_merge_requests_widget true

Or target specific actors instead:

/chatops gitlab run feature set --project=gitlab-org/gitlab,gitlab-org/gitlab-foss homepage_merge_requests_widget true
/chatops gitlab run feature set --group=gitlab-org,gitlab-com homepage_merge_requests_widget true
/chatops gitlab run feature set --user=marco-tom homepage_merge_requests_widget true

Before global rollout

Confirm the relevant gotchas before going to 100% — see enabling a feature for GitLab.com:

Cleanup

Remove the flag once deemed stable — see cleaning up. Track it here, or open a follow-up Feature Flag Cleanup issue. Remove the flag and its YAML definition from the codebase, then:

/chatops gitlab run release check <merge-request-url> <milestone>
/chatops gitlab run feature delete homepage_merge_requests_widget --dev --pre --staging --staging-ref --production

Rollback

/chatops gitlab run feature set homepage_merge_requests_widget false                                         # production
/chatops gitlab run feature set homepage_merge_requests_widget false --dev --pre --staging --staging-ref     # non-production
/chatops gitlab run feature delete homepage_merge_requests_widget --dev --pre --staging --staging-ref --production  # remove entirely
Edited by Marco Tomasi