[FF] draft_note_merge_head_line_code -- render draft notes on the merge head diff

Summary

Roll out the fix currently behind the draft_note_merge_head_line_code feature flag.

The flag makes an unpublished review comment (draft note) resolve its line_code against the merge head diff — the diff the "Changes" page renders — by tracing the note's position onto the merge-ref-head, the same mechanism Discussions::CaptureDiffNotePositionService uses for published notes. Without it, a draft note's line_code is computed from the 3-way diff and matches no rendered line when the target branch has moved forward (base_sha != start_sha), so the comment is invisible on the diff. Introduced in !224697 (merged).

Supersedes the earlier rollout issue for draft_note_diff_file_from_merge_head, which gated an approach that did not handle the common case (target edits that shift the commented line's new-line number). That flag was renamed and its approach replaced with position tracing.

  • DRI: @marc_shaw
  • Team Slack channel: #<dri-team-channel>

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?

  • Low blast radius — read-path only. The flag only changes the line_code a draft note is serialized with for rendering. No writes, no migrations, no data-loss risk. The note's stored line_code (used when the draft is published) is unchanged.
  • Performance — when enabled, serializing a draft note on a diffable MR runs a Gitlab::Diff::PositionTracer (a Gitaly diff) to translate the position onto the merge-head diff. For a review with many draft notes that is N tracer calls at diffs-page render time. Watch MR diffs latency/error rates on https://dashboards.gitlab.net while ramping; if it's a concern, the follow-up is to precompute/store the head line_code like DiffNotePosition does for published notes.
  • No known correctness limitation: position tracing handles the case where the target's edits shift the commented line's new-line number (the common #590869 scenario).

Rollout

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

Non-production

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

Production — percentage rollout (wait ≥15 min between steps, watch dashboards):

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

Or target specific actors instead:

/chatops gitlab run feature set --project=gitlab-org/gitlab,gitlab-org/gitlab-foss draft_note_merge_head_line_code true
/chatops gitlab run feature set --group=gitlab-org,gitlab-com draft_note_merge_head_line_code true
/chatops gitlab run feature set --user=marc_shaw draft_note_merge_head_line_code 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. Remove the flag and its YAML definition from the codebase, then:

/chatops gitlab run release check https://gitlab.com/gitlab-org/gitlab/-/merge_requests/224697 <milestone>
/chatops gitlab run feature delete draft_note_merge_head_line_code --dev --pre --staging --staging-ref --production

Rollback

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