Add immediate MR thread when Fix Pipeline flow starts investigating a failure

Problem

Today the Fix Pipeline flow only comments on the merge request at the very end of its execution, after the new Draft MR with the fix has been created. There is no visual indicator on the failing MR that the flow has been triggered and is currently running. This means:

  • The MR author has no idea the flow is investigating the failure
  • The author races to fix the problem themselves, unaware help is on the way
  • By the time the flow's output appears (as a separate Draft MR), the author has often already moved on

This was identified in &21180 (note) by @fabiopitino.

Proposal

Change the Fix Pipeline flow to create a thread on the original MR immediately when it starts, rather than only commenting at the end. The thread should:

  1. On flow start: Create a new discussion thread on the MR noting that the flow has been triggered for the specific pipeline failure, including a link to the session ID
  2. During execution: Optionally update the thread with progress (e.g. "Identified root cause: ...")
  3. On completion: Update the thread with the outcome (fix committed, new MR opened, or diagnosis summary if no fix could be applied) and resolve the thread
  4. If pipeline fails again: iterate inside the same thread for a max of 3 times.

Problems this solves

Based on the analysis in verify-stage#633, this change addresses 3 of the 6 identified root causes for the flow's low acceptance rate (~7%), covering 72% of current-era failure MRs (43 of 59):

Problem MRs Affected % of Failures How this helps
Problem 1: Author fixes it themselves (<30 min) 16 27% Author sees "Flow is investigating..." thread immediately and has a reason to wait before racing to fix it themselves. Directly attacks the 1-minute closes.
Problem 2: Fix arrives too late (30 min–24 hrs) 22 37% Many agent MRs were closed without comment — the author never knew the flow ran. A thread on their MR (not a separate Draft MR) ensures they see the flow's work in context.
Problem 4: Stale MRs >24 hrs 5 8% A thread on the original MR is naturally visible the next time the author works on their branch. A separate Draft MR is easy to ignore for days.

Problems this does NOT solve

Implementation notes

  • The thread should be created as the first action of the flow, before any diagnosis work begins
  • The thread content should clearly identify which pipeline (ID + link) is being investigated
  • Include the session ID link so the author can follow the flow's reasoning in real time
  • On completion, the thread should be updated (not a new comment) and resolved
  • This change is independent of and complementary to the "commit to existing MR branch" change (gitlab#589268)
Edited by Fabio Pitino