Run merge request risk classification end to end

What does this MR do and why?

Everything needed to classify a merge request now exists, but nothing runs it. This is the part that does.

When a merge request is ready, this starts a classification, records that one is in progress so the widget can tell "running" from "never ran", and turns the answers the AI returns into a score.

It also gives up. A classification that never reports back is marked as failed, instead of sitting as pending forever. That is what a reviewer sees today when a run dies. The flow schedules the give-up timer from its before_start callback, next to the row it records. Before this change, nothing scheduled the timer at all. The timer reads the row's own idle time rather than its own age. Two runs can overlap for one merge request, so an earlier run's timer defers itself instead of failing a classification that a later run still works on. The timer still refuses to touch a result that did arrive.

The score is applied only while the row waits for one. A late result cannot leave a row that reads as fully scored but is marked failed. Both refusals are written to the log.

Two triggers can start a run for the same merge request at nearly the same time: the created trigger and the draft-to-ready trigger. Both runs report into one row, and the row has a unique index on the merge request. Before, the loser of that race raised an error that the trigger worker swallows, so that run never recorded its pending state. Now the loser reads the row the winner recorded.

The flow trigger platform starts this. Enabling the Risk Classification flow for a project registers triggers for merge request creation and for the draft-to-ready transition, which landed in !254545 (merged). The steps below drive it that way.

References

• Related to #609292 (closed)
• Phase 1 epic: &23131
• Also addresses #628770 (closed)

Screenshots or screen recordings

How to set up and validate locally

You need a migrated, running GDK with GitLab Duo and the Agent Platform working: Duo turned on and flows able to run. The flow is Ultimate only, so the top-level group needs an Ultimate license, and it must be a group and not a personal namespace.

1. Turn the feature flag on, in a Rails console:

   Feature.enable(:duo_mr_risk_classification)

2. Turn on the Risk Classification flow for the top-level group and for the project.

   For the group, go to Settings > GitLab Duo, then select Change configuration. Under Flow execution, select Allow flow execution and Allow foundational flows. Then select the Risk Classification checkbox. Select Save changes.

   The group save starts a background job. This job creates the flow's service account and its triggers. Wait for Sidekiq to finish this job before you go to the next step.

3. Confirm that the flow setup created the triggers.

   In the project, go to AI > Triggers in the left sidebar.

   Check for a trigger named Auto-created triggers for Risk Classification. Its target is Risk Classification, and its status toggle is on.

4. Start a classification from the UI. Either open a new merge request in that project, or take a merge request that is in draft and select Mark as ready. Both events start the flow. Turn the flow on before you create the merge request: the creation event is published only when the project already has an active trigger. A classification record is created before the flow starts, so the widget can report that a run is in progress.

5. Read the widget on the merge request page. For a new merge request, it shows New risk assessment queued while the flow runs, then Risk assessment with a risk tier badge, a confidence badge, and the signal breakdown. For a merge request that already has a score, it shows Risk assessment updating and keeps showing the old badges until the new score is ready.

6. Confirm the give-up path without waiting 30 minutes. Set mr to the merge request you just used:

   mr.risk_assessment.update_column(:updated_at, 31.minutes.ago)
   Ai::RiskClassification::TimeoutWorker.new.perform(mr.id)
   
   mr.risk_assessment.reload.status   # => "failed"

   Without the backdated timestamp, the worker reschedules itself and leaves the row alone, which is what stops an old timer from failing a fresh run.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.