[FF] mr_ai_overview - replacement merge request Overview tab behind a user toggle

Summary

Roll out the feature currently behind the mr_ai_overview feature flag.

The flag does not turn the new experience on by itself. It makes a Try the new overview item appear in the merge request overflow menu; each user opts in and out for themselves, and the opt-in is a mr_ai_overview_enabled cookie that lasts a year. Same shape as Rapid Diffs.

Introduced by !252481 (merged), built up over !252997, !252998 and !252999.

Note

Process and guidance live in the docs - this issue is just the commands and a place to track the rollout. Feature flag controls · Feature flag lifecycle

What could go wrong?

Blast radius is a single opted-in user at a time. With the flag on and nobody opted in, the only change to the merge request page is two false data attributes on the overflow menu container. Verified by rendering all four merge request tabs with the flag off and diffing against the merge base: the only other differences were per-request values (correlation id, CSP nonce, two timestamps).

The opt-in replaces the whole Overview tab. No merge widget, no discussion thread, no issuable sidebar, so an opted-in user cannot merge or read discussions without switching back. That is the deliberate design, not a defect, but it is the main reason someone would opt straight back out.

Two known gaps while a user is opted in. Both need watching during the rollout, neither throws:

  1. window.gl.mrWidgetData is never defined, because the partial that creates it is the merge widget. The Pipelines tab therefore mounts with a null merge request id and empty project paths, so the GraphQL pipelines table and "run pipeline" lose their inputs.
  2. The sticky header's thread counter is hidden on the Overview tab, because only init_notes.js and the classic diffs app emit fetch-notes-data, and the notes app is not mounted. It appears once the user opens Changes.

What to measure before this flag changes type or goes wider:

  • Whether opted-in users stay opted in, or flip back within a session. That is the actual signal this flag exists to collect.
  • The cost of the mrAiOverview GraphQL query per Overview view. It reads only existing MergeRequest fields, but it is one extra request per page view that the classic tab does not make.
  • Whether the two gaps above generate reports, and whether either needs fixing before the flag widens beyond internal use.

Rollout

The feature actor is the project's root ancestor, so target groups rather than projects or users.

Non-production

/chatops gitlab run feature set mr_ai_overview true --dev --pre --staging --staging-ref

Production - this flag is for internal feedback first, so start with gitlab-org rather than a percentage:

/chatops gitlab run feature set --group=gitlab-org,gitlab-com mr_ai_overview true

Only move to a percentage rollout once the experience is worth showing to customers:

/chatops gitlab run feature set mr_ai_overview <percentage> --actors

Before global rollout

This is a wip flag and the experience is not finished, so global rollout is not the near-term plan. Before it ever goes to 100%:

  • Change the flag type from wip to beta, which is what makes the wider rollout checklist apply at all
  • Docs + version history updated
  • Both gaps above either fixed or accepted in writing
  • The merge widget question answered - either the new overview grows one, or opted-in users are expected to switch back to merge

Cleanup

Remove the flag once deemed stable - see cleaning up. Removing the flag also means deciding what happens to the cookie and the toggle: either the new overview becomes the only overview and both disappear, or the toggle becomes a real user preference rather than a cookie.

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

Rollback

/chatops gitlab run feature set mr_ai_overview false                                         # production
/chatops gitlab run feature set mr_ai_overview false --dev --pre --staging --staging-ref     # non-production
/chatops gitlab run feature delete mr_ai_overview --dev --pre --staging --staging-ref --production  # remove entirely

Turning the flag off is enough on its own - a user with the cookie still set falls straight back to the classic Overview tab, verified on GDK.