Today an API client can read merge request conflicts through GraphQL (`MergeRequest.conflictFiles`), but resolving them only works through the web conflicts page, which needs a browser session. The GitLab mobile app already shows conflicts natively using `conflictFiles`, but has to send the user to a browser to fix them. This epic adds a GraphQL mutation that resolves conflicts with the same result as the web UI, so a client like the mobile app can do the whole flow itself. A first attempt at this (gitlab-org/gitlab!256973, gitlab-org/gitlab!256975, gitlab-org/gitlab!256558) was closed unmerged on 2026-09-25. The refactor MR mixed a pure code move with several behaviour changes at once, which made it hard to review. This time the work is split so the refactor stays behaviour-neutral and each behaviour change gets its own issue. ## Plan - gitlab-org/gitlab#630903 - Return a `ServiceResponse` from `MergeRequests::Conflicts::ResolveService`, moving the controller's checks into the service with no behaviour change. No dependencies, do this first. - gitlab-org/gitlab#630904 - Validate conflict resolution input before calling Gitaly, so a bad path or malformed input gets a clear error instead of looking like a Gitaly outage. Depends on gitlab-org/gitlab#630903. - gitlab-org/gitlab#630905 - Tell already-resolved and still-checking merge requests apart when resolving conflicts, fixing a wrong 404 and a misleading message. Depends on gitlab-org/gitlab#630903. - gitlab-org/gitlab#630906 - Report Gitaly unavailability from `MergeRequests::Conflicts::ResolveService`, since GraphQL has no equivalent to the controller's Gitaly rescue. Depends on gitlab-org/gitlab#630903, blocks gitlab-org/gitlab#630908. - gitlab-org/gitlab#630907 - Expose conflict sections on `MergeRequest.conflictFiles`, adding the read-side data a client needs to resolve a conflict section by section. Independent of gitlab-org/gitlab#630903 to gitlab-org/gitlab#630906, can proceed in parallel, blocks gitlab-org/gitlab#630908. - gitlab-org/gitlab#630908 - Add `mergeRequestResolveConflicts` GraphQL mutation, the actual resolve endpoint. Depends on gitlab-org/gitlab#630903, gitlab-org/gitlab#630904, gitlab-org/gitlab#630905, gitlab-org/gitlab#630906, gitlab-org/gitlab#630907. <details> <summary>Detailed context for AI agents</summary> **Goal:** let API clients resolve merge request conflicts with the same result as the web UI produces today. **Current read side:** `MergeRequest.conflictFiles` was added in gitlab-org/gitlab!249456 as an experimental field. It returns `ourPath`, `theirPath`, and raw `content` with conflict markers, but no parsed sections, so a client cannot currently compute the section ids it would need to resolve a conflict section-by-section (only whole-file `content` resolution is possible from GraphQL data alone). **Current write side:** `Projects::MergeRequests::ConflictsController#resolve_conflicts` is the only way to resolve conflicts, and it requires a browser session (cookie-based auth, CSRF, etc). It is not usable from a mobile app or a personal access token / OAuth client. **Prior art and why it was reworked:** the first attempt split into three MRs: - gitlab-org/gitlab!256973 - move the controller's gates (push access, resolvable-in-UI, already-resolved check, error rescue) into `MergeRequests::Conflicts::ResolveService`. - gitlab-org/gitlab!256975 - expose `sections` on `conflictFiles`. - gitlab-org/gitlab!256558 - the `mergeRequestResolveConflicts` mutation itself. All three were closed unmerged on 2026-09-25. The main problem was that gitlab-org/gitlab!256973 mixed a pure move with behaviour changes (status codes and messages changed compared to master) in one MR, which made it hard to tell what was a refactor and what was a fix. This plan fixes that by keeping gitlab-org/gitlab#630903 strictly behaviour-neutral (proved by the existing controller spec passing unchanged) and giving each behaviour change (gitlab-org/gitlab#630904, gitlab-org/gitlab#630905, gitlab-org/gitlab#630906) its own issue and its own MR. The review threads on gitlab-org/gitlab!256558 and gitlab-org/gitlab!256973 contain useful probes and edge cases worth re-reading when picking up gitlab-org/gitlab#630903 through gitlab-org/gitlab#630906 and gitlab-org/gitlab#630908. **Related work, not part of this epic:** - gitlab-org/gitlab#621919 - expose `conflictType` on `conflictFiles` so binary or otherwise unresolvable conflicts are visible on the read side. Touches the same `Types::MergeRequests::ConflictType`, so gitlab-org/gitlab#630907 should coordinate with it to avoid schema conflicts. - Epic &20688 - Resolve conflict with Duo. Related goal (resolving conflicts without the web UI) but a separate initiative with its own approach. **Sequencing rationale:** gitlab-org/gitlab#630903 must land first because it is the foundation every other issue builds on (the service's `ServiceResponse` shape and reason constants). gitlab-org/gitlab#630904, gitlab-org/gitlab#630905, and gitlab-org/gitlab#630906 are independent of each other but all depend on gitlab-org/gitlab#630903's shape existing. gitlab-org/gitlab#630907 touches only the GraphQL read side (`Types::MergeRequests::ConflictType`) and has no dependency on the service work, so it can be done any time in parallel. gitlab-org/gitlab#630908 is last because the mutation needs the finished service interface (clean response, validated input, distinguishable error reasons for messages) and the section ids from gitlab-org/gitlab#630907 to build its `files` input and request spec. </details>